unsubscribe

2001-11-30 Thread Wency Arzadon

unsubscribe [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Our Community...Let's Get Connected.

2001-11-30 Thread Places Of Color
Title: Places Of Color




 



  



  
  
  
  
  
   



  Do

you see your preview? If not, please click here.

  

  


To
unsubscribe, click
here


Re: lock order reversal with pcm..

2001-11-30 Thread cameron grant

> and the sound cracks/stops playing for the fraction of a second. seems
> like it happens more often during disk or network activity ( i mount
> /usr/ports via nfs, and when i build a port it happens all the time). the
> soundcard is a sblive. i searched the archive for this problem, but didnt
> find anything, so i thought i report it. would be cool if someone has a
> fix for that.

known issue, will be fixed sometime soon.

-cg



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



lock order reversal with pcm..

2001-11-30 Thread Bernhard Valenti

hi,

i'm running -current as of november 10th. when i'm playing sound over the
dsp i sometimes get:

lock order reversal
 1st 0xc19aea00 pcm0 @
/usr/src/sys/modules/sound/pcm/../../../dev/sound/pcm/sound.c:132
 2nd 0xc19ae8c0 pcm0:play:0 @
/usr/src/sys/modules/sound/pcm/../../../dev/sound/pcm/sound.c:189

and the sound cracks/stops playing for the fraction of a second. seems
like it happens more often during disk or network activity ( i mount
/usr/ports via nfs, and when i build a port it happens all the time). the
soundcard is a sblive. i searched the archive for this problem, but didnt
find anything, so i thought i report it. would be cool if someone has a
fix for that.

regards,
bernhard

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: SoundBlaster PCI-128 performance

2001-11-30 Thread Kenneth Wayne Culver

maybe you did. I'm not sure what the problem is then.

Ken

On 30 Nov 2001, Seth Kingsley wrote:

> On Fri, Nov 30, 2001 at 09:12:52AM -0500, Kenneth Culver wrote:
> > On Friday 30 November 2001 02:44 am, you wrote:
> > Have you tried different speakers? Also have you tried moving the soundcard 
> > to a different slot? maybe some other card is causing interferance. I have a 
> > card that uses the same driver and havn't had a problem.
> 
> Oops, did I neglect to mention that it works perfectly under Windows 98
> SE?
> 
> -- 
> || Seth Kingsley || Meow Meow Fluff Fluff || [EMAIL PROTECTED] ||
> || rndcontrol -s 0 ||
> 


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: SoundBlaster PCI-128 performance

2001-11-30 Thread Seth Kingsley

On Fri, Nov 30, 2001 at 09:12:52AM -0500, Kenneth Culver wrote:
> On Friday 30 November 2001 02:44 am, you wrote:
> Have you tried different speakers? Also have you tried moving the soundcard 
> to a different slot? maybe some other card is causing interferance. I have a 
> card that uses the same driver and havn't had a problem.

Oops, did I neglect to mention that it works perfectly under Windows 98
SE?

-- 
|| Seth Kingsley || Meow Meow Fluff Fluff || [EMAIL PROTECTED] ||
|| rndcontrol -s 0 ||



msg32623/pgp0.pgp
Description: PGP signature


Re: Possible libc_r pthread bug

2001-11-30 Thread Alfred Perlstein

* Louis-Philippe Gagnon <[EMAIL PROTECTED]> [011130 15:57] wrote:
> If at first you don't succeed...
> 
> I've encountered a problem using pthread_cancel, pthread_join and 
> pthread_setcanceltype, I'm hoping someone can shed some light.

Provide me with minimal sample code and a makefile and i should
have the problem fixed in a couple of days, either that or a scathing
flame for you misusing the API. :)

-Alfred

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: Possible libc_r pthread bug

2001-11-30 Thread Daniel Eischen

On Fri, 30 Nov 2001, Louis-Philippe Gagnon wrote:
> If at first you don't succeed...
> 
> I've encountered a problem using pthread_cancel, pthread_join and 
> pthread_setcanceltype, I'm hoping someone can shed some light.
> 
> (in a nutshell : pthread_setcanceltype doesn't seem to work in FreeBSD 4.4)
> 
> (posted to -current and -hackers; if there's a more appropriate mailing list 
> for this, please let me know)
> 
> I recently encountered a situation where, after calling pthread_cancel to 
> cancel a thread, the call to pthread_join hangs indefinitely. I quickly figured
> out that it was because the thread being cancelled was never reaching a 
> cancellation point (in fact it was an infinite loop with no function calls at all). 
> Sure enough, adding a pthread_testcancel() in the loop allowed
> pthread_join to return. However this solution isn't acceptable for my requirements.
> 
> I discovered the pthread_setcanceltype function and its 
> PTHREAD_CANCEL_ASYNCHRONOUS parameter, which looked like 
> they would give me exactly what I needed : allow threads to be cancelled 
> regardless of what they are doing (basically a pthread equivalent to 
> TerminateThread).
> 
> Unfortunately, my tests have been less than conclusive : pthread_setcanceltype
> doesn't seem to do anything at all. It tells me it succeeds, subsequent calls 
> properly report the previous cancellation type as ASYNCHRONOUS. 
> But pthread_join still hangs, and adding pthread_testcancel calls still 
> makes it work...
> 
> I'm working on a FreeBSD 4.4-release machine; I ran the same test under 
> FreeBSD 4.3-release and got the same results. However, running it on a 
> Linux box (Mandrake release, 2.4.x kernel), I get exactly the results I 
> was expecting (that is, setting the cancellation type to asynchronous allows
> the thread to be cancelled at any time)
> 
> see the end of this message for my test program
> 
> So the questions are
> -am I doing something wrong or misinterpreting the man pages?

No, not really.

> -if not, is this a known bug?

Or feature?

> -if so, is there a workaround (or is it already fixed)?

Not fixed.  Work-around could be to use pthread_signal and
exit the thread from there.

> -if not, can someone investigate? (I once had a look at the libc_r code 
>  and ran away screaming)

Since your thread is compute bound, it is only woken up from the
thread library's scheduling signal handler.  In this case, it can
only resume the thread from the interrupted context, and so there
is no check for the thread being canceled.

-- 
Dan Eischen

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Possible libc_r pthread bug

2001-11-30 Thread Louis-Philippe Gagnon

If at first you don't succeed...

I've encountered a problem using pthread_cancel, pthread_join and 
pthread_setcanceltype, I'm hoping someone can shed some light.

(in a nutshell : pthread_setcanceltype doesn't seem to work in FreeBSD 4.4)

(posted to -current and -hackers; if there's a more appropriate mailing list 
for this, please let me know)

I recently encountered a situation where, after calling pthread_cancel to 
cancel a thread, the call to pthread_join hangs indefinitely. I quickly figured
out that it was because the thread being cancelled was never reaching a 
cancellation point (in fact it was an infinite loop with no function calls at all). 
Sure enough, adding a pthread_testcancel() in the loop allowed
pthread_join to return. However this solution isn't acceptable for my requirements.

I discovered the pthread_setcanceltype function and its 
PTHREAD_CANCEL_ASYNCHRONOUS parameter, which looked like 
they would give me exactly what I needed : allow threads to be cancelled 
regardless of what they are doing (basically a pthread equivalent to 
TerminateThread).

Unfortunately, my tests have been less than conclusive : pthread_setcanceltype
doesn't seem to do anything at all. It tells me it succeeds, subsequent calls 
properly report the previous cancellation type as ASYNCHRONOUS. 
But pthread_join still hangs, and adding pthread_testcancel calls still 
makes it work...

I'm working on a FreeBSD 4.4-release machine; I ran the same test under 
FreeBSD 4.3-release and got the same results. However, running it on a 
Linux box (Mandrake release, 2.4.x kernel), I get exactly the results I 
was expecting (that is, setting the cancellation type to asynchronous allows
the thread to be cancelled at any time)

see the end of this message for my test program

So the questions are
-am I doing something wrong or misinterpreting the man pages?
-if not, is this a known bug?
-if so, is there a workaround (or is it already fixed)?
-if not, can someone investigate? (I once had a look at the libc_r code 
 and ran away screaming)

If this turns out to be a bug in libc_r, a suggestion for a work-around 
(even a hack) would be much appreciated, even if a proper fix is found and 
committed to CVS (requiring an upgrade from 4.4-release installations is 
something we'd rather avoid).


now for some disclaimers :

I'm aware that asynchronous cancellations (TerminateThread-style) are an 
Evil Thing To Do. Unfortunately I have no choice in the matter.

I'm aware that there are some strict limitations on what a thread is "allowed" 
to do while its cancellation type is asynchronous. specifically, it should only 
call "cancel-safe" functions. Note that in my test program, the thread being 
cancelled doesn't call any functions at all after setting its cancellation type, so 
this shouldn't be an issue.


now for the code :


#include 
#include 

/* thread entry point */
void * thread_entry (void *arg)
{
   int i;

   if(0!=pthread_setcanceltype(PTHREAD_CANCEL_ASYNCHRONOUS,NULL))
   {
  fprintf(stderr,"setcanceltype failed!\n");
   }

   fprintf(stderr,"thread_entry entering loop\n");
   while(1)
   {
  i++;
/* uncomment this to insert a cancellation point */
/*  pthread_testcancel();*/
   }
/* if we see this, it would mean the loop has been optimized out... */
   fprintf(stderr, "after loop\n");
}

int main(void)
{
   pthread_t thread;
   pthread_attr_t attr;
   void *pthread_param;

   pthread_attr_init(&attr);

   fprintf(stderr,"creating thread\n");
   pthread_create(&thread,&attr,&thread_entry,NULL);

   fprintf(stderr,"thread created; hit enter to cancel it...\n");
   getchar();
   fprintf(stderr,"cancelling...\n");
   if(0!=pthread_cancel(thread))
   {
  fprintf(stderr,"cancel failed!\n");
   }
   fprintf(stderr,"after cancel, before join...\n");
   if(0!=pthread_join(thread,&pthread_param))
   {
  fprintf(stderr,"join failed!\n");
   }
   fprintf(stderr,"after join\n");
}

please ask if more details are needed

Thanks in advance,

Louis-Philippe Gagnon ~ [EMAIL PROTECTED]
Macadamian Technologies
"Software experts for the world's leading technology companies."
http://www.macadamian.com



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: df -l broken

2001-11-30 Thread Joerg Wunsch

As Maxime Henrion wrote:

> > Seems to work.  mount(8) has still the problem though:
> 
> Great, I'll file a PR for it.  Thanks for the feedback !

I can commit it if you want.

> I fail to see why should ``mount -t local'' work.

ISTR that it used to work, at least in the context of
"mount -a -t local".

I can't seem to find any old system to verify this claim, however.

So maybe it's merely wishful thinking instead of something that
has actually once been there...
-- 
cheers, J"org   .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: What happened to current.freebsd.org again?

2001-11-30 Thread Anders Andersson

On Fri, Nov 30, 2001 at 06:01:08PM +0100, Georg-W. Koltermann wrote:
> Hello,
> 
> since some time again I can't get to ftp://current.freebsd.org to
> download current snapshots and packages.  Is the machine broken again?

In the meantime you could use ftp://snapshots.jp.freebsd.org/
-- 
Anders Andersson <[EMAIL PROTECTED]>
UNIX, Networking and Security consultant
(+46) 705 87 53 35

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



What happened to current.freebsd.org again?

2001-11-30 Thread Georg-W. Koltermann

Hello,

since some time again I can't get to ftp://current.freebsd.org to
download current snapshots and packages.  Is the machine broken again?

--
Regards,
Georg.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



RE: ntfs fs

2001-11-30 Thread Jan Stocker

Okay,
i'll send you a callstack if i am at work again (have now a week holiday).
The current kernel wasnt compiled with debug info...

Jan

> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Steve Kargl
> Sent: Thursday, November 29, 2001 8:18 PM
> To: [EMAIL PROTECTED]
> Cc: freebsd-current@FreeBSD. ORG
> Subject: Re: ntfs fs
>
>
> On Thu, Nov 29, 2001 at 08:03:55PM +0100, Jan Stocker wrote:
> > Hi,
> > after a 'ls -l' on a ntfs mounted partition my system freezes
> and reboots. A
> > normal 'ls' really runs quite fine...
> >
>
> Jan,
>
> This message contains very little useful information.  See
>
> http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbo
ok/kerneldebug.html

--
Steve

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: df -l broken

2001-11-30 Thread Maxime Henrion

Joerg Wunsch wrote:
> Maxime Henrion <[EMAIL PROTECTED]> wrote:
> 
> > I looked at the code a bit more closely and you're entirely right.  I
> > think I figured out why my patch caused a core dump.  Here is a more
> > correct patch that should fix the problem without causing core dumps.
> 
> Seems to work.  mount(8) has still the problem though:

Great, I'll file a PR for it.  Thanks for the feedback !

> uriah # mount -t local
> uriah # kldload nfs
> uriah # mount -t local
> uriah # mount -t nonfs
> /dev/da0a on / (ufs, local, soft-updates)
> devfs on /dev (devfs, local)
> /dev/vinum/var on /var (ufs, local, soft-updates)
> /dev/vinum/usr on /usr (ufs, local, soft-updates)
> /dev/vinum/home on /home (ufs, local, soft-updates)
> /dev/vinum/home_cvs on /home/cvs (ufs, NFS exported, local, soft-updates)
> /dev/vinum/src on /usr/src (ufs, local, soft-updates)
> /dev/vinum/othersrc on /usr/othersrc (ufs, local, soft-updates)
> /dev/vinum/obj on /usr/obj (ufs, local, soft-updates)
> /dev/vinum/ports on /usr/ports (ufs, local, soft-updates)
> /dev/vinum/distfiles on /usr/ports/distfiles (ufs, NFS exported, local, soft-updates)
> /dev/vinum/news on /var/spool/news (ufs, local, soft-updates)
> /dev/vinum/tmp on /tmp (ufs, NFS exported, local, soft-updates)
> /dev/vinum/release on /usr/release (ufs, NFS exported, local, soft-updates)
> /dev/vinum/junk on /junk (ufs, local, soft-updates)
> procfs on /proc (procfs, local, read-only)

I fail to see why should ``mount -t local'' work.  I don't see anything
related in the mount(8) manpage.  To my knowledge, -t is only used when
specifying a particular fs type (nfs, msdosfs, ...) optionally prepended
with a ``no''.  If you point me to the relevant documentation, I'll be
happy to fix this bug too.

Thanks,
Maxime Henrion
-- 
Don't be fooled by cheap finnish imitations ; BSD is the One True Code

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: SoundBlaster PCI-128 performance

2001-11-30 Thread Kenneth Culver

On Friday 30 November 2001 02:44 am, you wrote:
Have you tried different speakers? Also have you tried moving the soundcard 
to a different slot? maybe some other card is causing interferance. I have a 
card that uses the same driver and havn't had a problem.

Ken

> I'm getting low volume, background noise, and slight distortion playing
> audio through my SoundBlaster PCI-128.  I tested it using mpg123,
> mpg321, vlc, and ogle.  I am running a recent -current:
>
> FreeBSD 5.0-CURRENT #2: Wed Nov 28 23:28:15 PST 2001
> [EMAIL PROTECTED]:/usr/src/sys/i386/compile/NEKO
>
> And the boot -v:
>
> pcm0:  port 0xd800-0xd83f irq 5 at device 12.0 on
> pci0
> pcm0: ac97 codec id 0x83847608 (SigmaTel STAC9708/9711)
> pcm0: ac97 codec features 18 bit DAC, 18 bit ADC, 5 bit master volume,
> SigmaTel 3D Enhancement
> pcm0: ac97 primary codec extended features surround DAC
> pcm: setmap 40c000, 1000; 0xc1258000 -> 40c000
> pcm: setmap 3cf000, 1000; 0xc125b000 -> 3cf000
> pcm-: pcm0 already exists, skipping it
>
> PnP OS is disabled in my BIOS.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



strange things with Mouse Support and Copy-and-Past

2001-11-30 Thread Juriy Goloveshkin

I often use mouse for copy-and-past operations in text consoles.
but I see that fresh CURRENT has someshing strange.
next string is pasted from buffer:
nextstringispastedfrombuffer:

I think something is broken or changed. 
Is there a way to have Copy-and-Past back? what's wrong?

-- 
bye
Juriy Goloveshkin

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: ntfs fs

2001-11-30 Thread Sheldon Hearn



On Thu, 29 Nov 2001 20:03:55 +0100, Jan Stocker wrote:

| after a 'ls -l' on a ntfs mounted partition my system freezes and reboots. A
| normal 'ls' really runs quite fine...

Weird, I get a panic, not an uninformative reboot.  I didn't do anything
about it, since I don't know who looks after ntfs and didn't have time
to look at the backtrace. :-(

Ciao,
Sheldon.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



snd_pcm bringing its problems (sound.c)

2001-11-30 Thread Hiten Pandya

hello...
greetings,

everytime i used to play CDs, MP3 or any audio,
it gives a lock order reversal notice... the following
is my dmesg -a output...

lock order reversal
 1st 0xc65b6e80 pcm0 @
/data/dev/src/sys/modules/sound/pcm/../../../dev/sound/pcm/sound.c:132
 2nd 0xc65b6d40 pcm0:play:0 @
/data/dev/src/sys/modules/sound/pcm/../../../dev/sound/pcm/sound.c:189


as i can play all the audio correctly without any
problems... but its just that the lock order
reversal should not be there.. i beleive

i have a SoundBlast Live! card, which is supported by
FreeBSD under the Emu10k1 driver... and two
processors enabled as well as all the kernel debugging
options...

i am attaching my 'dmesg -a' output with this
message..

help is appreciated...
thanks..

Yours Sincerely,
Hiten Pandya

<[EMAIL PROTECTED]>



__
Do You Yahoo!?
Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month.
http://geocities.yahoo.com/ps/info1

Copyright (c) 1992-2001 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 5.0-CURRENT #8: Thu Nov 29 10:24:42 GMT 2001
[EMAIL PROTECTED]:/usr/obj/data/dev/src/sys/CURRENT5
Preloaded elf kernel "/boot/kernel/kernel" at 0xc041f000.
Preloaded elf module "/boot/kernel/acpi.ko" at 0xc041f0a8.
Preloaded elf module "/boot/kernel/linux.ko" at 0xc041f154.
Preloaded elf module "/boot/kernel/snd_pcm.ko" at 0xc041f200.
Preloaded elf module "/boot/kernel/snd_emu10k1.ko" at 0xc041f2ac.
module linux already present!
Timecounter "i8254"  frequency 1193182 Hz
CPU: Pentium III/Pentium III Xeon/Celeron (730.81-MHz 686-class CPU)
  Origin = "GenuineIntel"  Id = 0x683  Stepping = 3
  
Features=0x387fbff
real memory  = 536870912 (524288K bytes)
avail memory = 516411392 (504308K bytes)
Programming 24 pins in IOAPIC #0
IOAPIC #0 intpin 2 -> irq 0
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
 cpu0 (BSP): apic id:  0, version: 0x00040011, at 0xfee0
 cpu1 (AP):  apic id:  1, version: 0x00040011, at 0xfee0
 io0 (APIC): apic id:  2, version: 0x00170011, at 0xfec0
Pentium Pro MTRR support enabled
VESA: v3.0, 32768k memory, flags:0x1, mode table:0xc0332182 (122)
VESA: NVidia
Using $PIR table, 8 entries at 0xc00f7100
ACPI-0161: *** Error: AcpiLoadTables: Could not get RSDP, AE_NO_ACPI_TABLES
ACPI-0213: *** Error: AcpiLoadTables: Could not load tables: AE_NO_ACPI_TABLES
ACPI: table load failed: AE_NO_ACPI_TABLES
npx0:  on motherboard
npx0: INT 16 interface
pcib0:  at pcibus 0 on motherboard
pci0:  on pcib0
pcib1:  at device 1.0 on pci0
pci1:  on pcib1
pci1:  at device 0.0 (no driver attached)
isab0:  at device 7.0 on pci0
isa0:  on isab0
atapci0:  port 0xffa0-0xffaf at device 7.1 on pci0
ata0: at 0x1f0 irq 14 on atapci0
ata1: at 0x170 irq 15 on atapci0
pci0:  at device 7.2 (no driver attached)
pci0:  at device 7.3 (no driver attached)
pci0:  at device 7.4 (no driver attached)
fxp0:  port 0xd000-0xd03f mem 
0xdfe0-0xdfef,0xdffef000-0xdffe irq 9 at device 9.0 on pci0
fxp0: Ethernet address 00:06:29:af:90:cf
inphy0:  on miibus0
inphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
pcm0:  port 0xd400-0xd41f irq 10 at device 11.0 on pci0
pci0:  at device 12.0 (no driver attached)
ata-: ata0 already exists, skipping it
ata-: ata1 already exists, skipping it
sc-: sc0 already exists, skipping it
vga-: vga0 already exists, skipping it
atkbdc0:  at port 0x60,0x64 on isa0
atkbd0:  flags 0x1 irq 1 on atkbdc0
kbd0 at atkbd0
psm0:  irq 12 on atkbdc0
psm0: model IntelliMouse, device ID 3
fdc0:  at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0
fdc0: FIFO enabled, 8 bytes threshold
fd0: <1440-KB 3.5" drive> on fdc0 drive 0
pmtimer0 on isa0
ppc0:  at port 0x378-0x37f irq 7 on isa0
ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode
ppc0: FIFO with 16/16/8 bytes threshold
plip0:  on ppbus0
lpt0:  on ppbus0
lpt0: Interrupt-driven port
ppi0:  on ppbus0
sc0:  at flags 0x100 on isa0
sc0: VGA <16 virtual consoles, flags=0x300>
sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0
sio0: type 16550A
sio1 at port 0x2f8-0x2ff irq 3 on isa0
sio1: type 16550A
vga0:  at port 0x3c0-0x3df iomem 0xa-0xb on isa0
APIC_IO: Testing 8254 interrupt delivery
APIC_IO: routing 8254 via IOAPIC #0 intpin 2
Profiling kernel, textsize=1475936 [c0123590..c028baf0]
cputime 6172, empty_loop 9, nullfunc_loop_profiled 6230, mcount 6172, mexitcount 6171
Profiling overheads: mcount: 6161+0, 6226+-65; mexitcount: 6161+0, 6167+-6 nsec
Profiling overheads: mcount: 941+0, 951+-10; mexitcount: 941+0, 942+-1 cycles
ad0: 28629MB  [58168/16/63] at ata0-master UDMA66
acd0: DVD-ROM  at ata0-slave PIO4
acd1: CD-RW  at ata1-slave PIO4
Mounting root from ufs:/dev/ad0s2a
SMP: AP CPU #1 Launched!
swapon: adding /dev/ad0s2b as swap device
Automatic boot in progress...
/dev/ad0s2a: FILESYSTEM CLEAN; SKIPPING C

Re: XFree86 3.3.6 dying

2001-11-30 Thread Maxim Sobolev

Peter Jeremy wrote:
> 
> With a recently re-built XFree86, running on -current from last Sunday,
> whenever I hit one of the keypad keys, the X server crashes.  This is
> somewhat disconcerting...
> 
> The kernel prints "sigreturn: eflags = 0x13282, was 0x256" (the old
> eflags value an addition I made to that printf whilst tracking down
> another problem).  These values are consistent.  The X server reports
> that it received SIGBUS and will core dump, but instead goes into a
> tight loop and needs kill -ABRT or kill -9 to recover.  This happens
> whether or not I'm logged in, after I use xmodmap to unmap the
> relevant keycodes and when the screen is locked.
> 
> ktrace on the Xserver shows the server reading a keycode from the
> keyboard, checking the mouse and getting EWOULDBLOCK then receiving
> a SIGBUS.
> 
> Has anyone else seen anything like this?

Apply the following patch and rebuild/reinstall your kernel:

http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/i386/include/psl.h.diff?r1=1.10&r2=1.11

-Maxim

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message