On all my test systems it run without any problems. But it are only Intel
Chipsets. So I can't reproduce it. Can you test it, without the nvidia module? 
In 2 systems I use the nvidia video module without any problems.

Here, the nasd problem does not occur on an SiS chipset system either, only on
the nForce4 chipset system. I uninstalled the (freshrpmss)
nvidia-x11-drv-1.0.9746-1.i386.rpm and rebooted; the same nasd error occurs.
Here is the text from /var/log/messages:

_________________________

Jan 19 12:59:28 callgirl kernel: BUG: unable to handle kernel NULL pointer
dereference at virtual address 00000001
Jan 19 12:59:28 callgirl kernel:  printing eip:
Jan 19 12:59:28 callgirl kernel: f8d0686f
Jan 19 12:59:28 callgirl kernel: *pde = 5eeb6067
Jan 19 12:59:28 callgirl kernel: Oops: 0000 [#1]
Jan 19 12:59:28 callgirl kernel: SMP 
Jan 19 12:59:28 callgirl kernel: last sysfs file:
/devices/pci0000:00/0000:00:08.0/irq
Jan 19 12:59:28 callgirl kernel: Modules linked in: nls_utf8 cifs nfs nfsd
exportfs nfs_acl autofs4 it87 hwmon_vid i2c_isa eeprom hidp l2cap bluetooth
vmnet(P)(U) vmmon(P)(U) lockd sunrpc ipv6 dm_multipath video sbs i2c_ec button
battery asus_acpi ac lp snd_usb_audio snd_seq_dummy snd_hda_intel sg
snd_hda_codec snd_seq_oss snd_seq_midi_event snd_seq snd_pcm_oss snd_mixer_oss
floppy snd_pcm k8temp k8_edac forcedeth i2c_nforce2 hwmon edac_mc pcspkr
parport_pc snd_timer nvidia(P)(U) parport snd_page_alloc snd_usb_lib snd_rawmidi
snd_seq_device i2c_core usblp snd_hwdep snd ide_cd serio_raw cdrom soundcore
dm_snapshot dm_zero dm_mirror dm_mod sata_nv libata sd_mod scsi_mod ext3 jbd
ehci_hcd ohci_hcd uhci_hcd
Jan 19 12:59:28 callgirl kernel: CPU:    0
Jan 19 12:59:28 callgirl kernel: EIP:    0060:[<f8d0686f>]    Tainted: P      VLI
Jan 19 12:59:28 callgirl kernel: EFLAGS: 00210202   (2.6.19-1.2895.fc6 #1)
Jan 19 12:59:28 callgirl kernel: EIP is at snd_interval_list+0x21/0xa6 [snd_pcm]
Jan 19 12:59:28 callgirl kernel: eax: 00000001   ebx: f3e5cd28   ecx: 00000000 
 edx: 00000001
Jan 19 12:59:28 callgirl kernel: esi: 00000013   edi: f3e5cc00   ebp: ffffffff 
 esp: f2a55cec
Jan 19 12:59:28 callgirl kernel: ds: 007b   es: 007b   ss: 0068
Jan 19 12:59:28 callgirl kernel: Process nasd (pid: 4563, ti=f2a55000
task=f293c4b0 task.ti=f2a55000)
Jan 19 12:59:28 callgirl kernel: Stack: f2a55e00 f3e5cc00 f3e5cc00 f2a55e34
f8d086d4 ffffffff f35492e0 00000017 
Jan 19 12:59:28 callgirl kernel:        f8d04ad8 00000002 00000003 00000004
00000005 00000006 00000007 00000008 
Jan 19 12:59:28 callgirl kernel:        00000009 0000000a 0000000b 0000000c
0000000d 0000000e 0000000f 00000010 
Jan 19 12:59:28 callgirl kernel: Call Trace:
Jan 19 12:59:28 callgirl kernel:  [<f8d086d4>] snd_pcm_hw_rule_list+0x25/0x29
[snd_pcm]
Jan 19 12:59:28 callgirl kernel:  [<f8d04ad8>] snd_pcm_hw_refine+0x260/0x3b8
[snd_pcm]
Jan 19 12:59:28 callgirl kernel:  [<f8d28107>]
snd_pcm_oss_change_params+0x1a8/0xc4f [snd_pcm_oss]
Jan 19 12:59:28 callgirl kernel:  [<f8d28eeb>]
snd_pcm_oss_get_active_substream+0x2c/0x43 [snd_pcm_oss]
Jan 19 12:59:28 callgirl kernel:  [<f8d28f2c>] snd_pcm_oss_get_formats+0xe/0xf9
[snd_pcm_oss]
Jan 19 12:59:28 callgirl kernel:  [<f8d29f9d>] snd_pcm_oss_ioctl+0x366/0x9ca
[snd_pcm_oss]
Jan 19 12:59:28 callgirl kernel:  [<c048022b>] do_ioctl+0x1f/0x62
Jan 19 12:59:28 callgirl kernel:  [<c04804b8>] vfs_ioctl+0x24a/0x25c
Jan 19 12:59:28 callgirl kernel:  [<c0480516>] sys_ioctl+0x4c/0x66
Jan 19 12:59:28 callgirl kernel:  [<c040404b>] syscall_call+0x7/0xb
Jan 19 12:59:28 callgirl kernel:  [<00b8e402>] 0xb8e402
Jan 19 12:59:28 callgirl kernel:  =======================
Jan 19 12:59:28 callgirl kernel: Code: 83 c4 40 89 c8 5b 5e 5f 5d c3 55 57 56 89
d6 53 8b 6c 24 14 89 ca 89 c3 31 c9 eb 21 85 ed 74 0b b8 01 00 00 00 d3 e0 85 c5
74 11 <8b> 04 8a 39 03 75 08 f6 43 08 01 75 04 eb 16 72 07 41 39 f1 75 
Jan 19 12:59:28 callgirl kernel: EIP: [<f8d0686f>] snd_interval_list+0x21/0xa6
[snd_pcm] SS:ESP 0068:f2a55cec
Jan 19 12:59:28 callgirl kernel:  <1>BUG: unable to handle kernel NULL pointer
dereference at virtual address 00000001
Jan 19 12:59:28 callgirl kernel:  printing eip:
Jan 19 12:59:28 callgirl kernel: f8d0686f
Jan 19 12:59:28 callgirl kernel: *pde = 00000000
Jan 19 12:59:28 callgirl kernel: Oops: 0000 [#2]
Jan 19 12:59:28 callgirl kernel: SMP 
Jan 19 12:59:28 callgirl kernel: last sysfs file:
/devices/pci0000:00/0000:00:08.0/irq
Jan 19 12:59:28 callgirl kernel: Modules linked in: nls_utf8 cifs nfs nfsd
exportfs nfs_acl autofs4 it87 hwmon_vid i2c_isa eeprom hidp l2cap bluetooth
vmnet(P)(U) vmmon(P)(U) lockd sunrpc ipv6 dm_multipath video sbs i2c_ec button
battery asus_acpi ac lp snd_usb_audio snd_seq_dummy snd_hda_intel sg
snd_hda_codec snd_seq_oss snd_seq_midi_event snd_seq snd_pcm_oss snd_mixer_oss
floppy snd_pcm k8temp k8_edac forcedeth i2c_nforce2 hwmon edac_mc pcspkr
parport_pc snd_timer nvidia(P)(U) parport snd_page_alloc snd_usb_lib snd_rawmidi
snd_seq_device i2c_core usblp snd_hwdep snd ide_cd serio_raw cdrom soundcore
dm_snapshot dm_zero dm_mirror dm_mod sata_nv libata sd_mod scsi_mod ext3 jbd
ehci_hcd ohci_hcd uhci_hcd
Jan 19 12:59:28 callgirl kernel: CPU:    0
Jan 19 12:59:28 callgirl kernel: EIP:    0060:[<f8d0686f>]    Tainted: P      VLI
Jan 19 12:59:28 callgirl kernel: EFLAGS: 00210202   (2.6.19-1.2895.fc6 #1)
Jan 19 12:59:28 callgirl kernel: EIP is at snd_interval_list+0x21/0xa6 [snd_pcm]
Jan 19 12:59:28 callgirl kernel: eax: 00000001   ebx: f69ec928   ecx: 00000000 
 edx: 00000001
Jan 19 12:59:28 callgirl kernel: esi: 00000013   edi: f69ec800   ebp: ffffffff 
 esp: f2a55948
Jan 19 12:59:28 callgirl kernel: ds: 007b   es: 007b   ss: 0068
Jan 19 12:59:28 callgirl kernel: Process nasd (pid: 4563, ti=f2a55000
task=f293c4b0 task.ti=f2a55000)
Jan 19 12:59:28 callgirl kernel: Stack: f2a55e00 f69ec800 f69ec800 f2a55a90
f8d086d4 ffffffff f35492e0 00000017 
Jan 19 12:59:28 callgirl kernel:        f8d04ad8 f659ab80 00000002 00000003
00000004 00000005 00000006 00000007 
Jan 19 12:59:28 callgirl kernel:        00000008 00000009 0000000a 0000000b
0000000c 0000000d 0000000e 0000000f 
Jan 19 12:59:28 callgirl kernel: Call Trace:
Jan 19 12:59:28 callgirl kernel:  [<f8d086d4>] snd_pcm_hw_rule_list+0x25/0x29
[snd_pcm]
Jan 19 12:59:28 callgirl kernel:  [<f8d04ad8>] snd_pcm_hw_refine+0x260/0x3b8
[snd_pcm]
Jan 19 12:59:28 callgirl kernel:  [<f8d28107>]
snd_pcm_oss_change_params+0x1a8/0xc4f [snd_pcm_oss]
Jan 19 12:59:28 callgirl kernel:  [<f8d28bc7>] snd_pcm_oss_make_ready+0x19/0x3f
[snd_pcm_oss]
Jan 19 12:59:28 callgirl kernel:  [<f8d29c03>] snd_pcm_oss_sync+0x24d/0x281
[snd_pcm_oss]
Jan 19 12:59:28 callgirl kernel:  [<f8d2a62d>] snd_pcm_oss_release+0x2c/0xa6
[snd_pcm_oss]
Jan 19 12:59:28 callgirl kernel:  [<c047674e>] __fput+0xba/0x190
Jan 19 12:59:28 callgirl kernel:  [<c04740f6>] filp_close+0x52/0x59
Jan 19 12:59:28 callgirl kernel:  [<c0428fdc>] put_files_struct+0x65/0xa7
Jan 19 12:59:28 callgirl kernel:  [<c042a1bf>] do_exit+0x246/0x787
Jan 19 12:59:28 callgirl kernel:  [<c0405719>] die+0x2c3/0x2e8
Jan 19 12:59:28 callgirl kernel:  [<c0627475>] do_page_fault+0x41c/0x4ef
Jan 19 12:59:28 callgirl kernel:  [<c0625ce1>] error_code+0x39/0x40
Jan 19 12:59:28 callgirl kernel:  [<f8d0686f>] snd_interval_list+0x21/0xa6 [snd_pcm]
Jan 19 12:59:28 callgirl kernel:  [<f8d086d4>] snd_pcm_hw_rule_list+0x25/0x29
[snd_pcm]
Jan 19 12:59:28 callgirl kernel:  [<f8d04ad8>] snd_pcm_hw_refine+0x260/0x3b8
[snd_pcm]
Jan 19 12:59:28 callgirl kernel:  [<f8d28107>]
snd_pcm_oss_change_params+0x1a8/0xc4f [snd_pcm_oss]
Jan 19 12:59:28 callgirl kernel:  [<f8d28eeb>]
snd_pcm_oss_get_active_substream+0x2c/0x43 [snd_pcm_oss]
Jan 19 12:59:28 callgirl kernel:  [<f8d28f2c>] snd_pcm_oss_get_formats+0xe/0xf9
[snd_pcm_oss]
Jan 19 12:59:28 callgirl kernel:  [<f8d29f9d>] snd_pcm_oss_ioctl+0x366/0x9ca
[snd_pcm_oss]
Jan 19 12:59:28 callgirl kernel:  [<c048022b>] do_ioctl+0x1f/0x62
Jan 19 12:59:28 callgirl kernel:  [<c04804b8>] vfs_ioctl+0x24a/0x25c
Jan 19 12:59:28 callgirl kernel:  [<c0480516>] sys_ioctl+0x4c/0x66
Jan 19 12:59:28 callgirl kernel:  [<c040404b>] syscall_call+0x7/0xb
Jan 19 12:59:28 callgirl kernel:  [<00b8e402>] 0xb8e402
Jan 19 12:59:28 callgirl kernel:  =======================
Jan 19 12:59:28 callgirl kernel: Code: 83 c4 40 89 c8 5b 5e 5f 5d c3 55 57 56 89
d6 53 8b 6c 24 14 89 ca 89 c3 31 c9 eb 21 85 ed 74 0b b8 01 00 00 00 d3 e0 85 c5
74 11 <8b> 04 8a 39 03 75 08 f6 43 08 01 75 04 eb 16 72 07 41 39 f1 75 
Jan 19 12:59:28 callgirl kernel: EIP: [<f8d0686f>] snd_interval_list+0x21/0xa6
[snd_pcm] SS:ESP 0068:f2a55948
Jan 19 12:59:28 callgirl kernel:  <1>Fixing recursive fault but reboot is needed!
_________________________

Also, note that while running with the (unkillable pid) nasd loaded after
startup and X startup, from terminal, yesterday the system's network interfaces
randomly stopped operating about eight times, requiring 'service network
restart' to restore their function. I suspect this may be related but am not
certain. Meanwhile I have removed nasd from /etc/rc.d/init.d, pending resolution
of this problem.

Argh.

Disregard above /var/log/messages paste; it is the same one as initially. My
bad. I failed to notice the date/time stamp on the section.

The nasd load (during interactive startup) *did* present the same error
messages, but these appear not to have been written to /var/log/messages. My
apologies for pasting the same clip twice.

I can repeat the experiment with nvidia driver once again removed, but since
this results in a configuration that will not start X, it isn't useful for
normal operation.

As an an workaround you can disable the nasd. But then you will not have sound
in application, that use the sound system in Qt. But it sound's like more an bug
in the nvidia sound module of the kernel.
To disable run chkconfig nasd off
Because I can't debug it(I don't have an nvidia chipset) you only can disable
nasd or better contact the developer via jon[at]radscan[dot]com

Thank you for the contact information! I would never have found that by myself ;-)

I will do as you suggest and contact him. This appears to be a bug that will not
affect all that many people, so I will be patient about a resolution.

And have you get any news for me?

I have been in touch with Jon Trulson per your suggestion, and his advice to
change the /etc/nas/nasd.conf input section option 'autoOpen' to 'no' does
appear to have eliminated the kernel fault on boot when nasd is enabled in startup.

However, another problem remains, which is both more serious (since nasd can be
removed from startup) and which may be closer to the real root of the problem.
Specifically, eth0 in the single-homed system drops randomly and must be
reinitialized with 'service network restart' or 'ifconfig eth0 down/up'.
Further, multiple (usually four) reboots or power cycles are usually required to
establish a working X session. There is a quasi-repeatable failure pattern to
the three failed boots preceding the fourth and working one.

I earlier misidentified the system mainboard (because I had the wrong manual
beside the system). It is actually the Asus M2N-E with the nForce 570 Ultra MPC
chipset, and my best guess at this point is that there are myriad aspects of the
2.6.19 kernel that are not well integrated for that chipset.

Because I lack the skillset to narrow these problems down in reportable fashion,
 I have been reluctant to file additional bug reports, especially given how
badly I messed up this one. Not only did I post the same (I later learned nearly
useless) trace twice, I also misidentified the mainboard affected.

Today I installed the updated nas-1.8-13.fc6 but have not yet loaded it. If
after restoring the nasd.conf to its original setting I find more to report, I
will do so.

Thank you for your help.

Ok I will wait for your next response.

Created attachment 148222 [details]
strace log for nasd started with autoOpen 'yes' in fc6

Comment on attachment 148222 [details]
strace log for nasd started with autoOpen 'yes' in fc6

With the update to 2.6.19-1.2911.fc6 and nas-1.8-13.fc6, I retested nasd
causing a kernel fault when confgiured 'normally' -- i.e., /etc/nas/nasd.conf
inputsection 'autoOpen "yes"'

I began by disabling nasd at startup, and at a root console entered:

strace -f -o ~/nasd_2.6.19-1.2911.fc6_panic_autoOpen-yes.trace /usr/bin/nasd
-aa -b

When it blew up, I logged in to another TTY and did 'sync' followed by reboot.

Attached is the trace file: nasd_2.6.19-1.2911.fc6_panic_autoOpen-yes.trace

I also tested it with /etc/nas/nasd.conf 'autoOpen "no"' using the same
procedure as above but with a different trace filename.

This did not blow up exactly, but would not return a bash prompt, so again I
logged to another TTY and did sync and reboot.

Attahced is the trace file: nasd_2.6.19-1.2911.fc6_panic_autoOpen-no.trace

I hope this information is helpful. Please let me know if there is anything
else I can do to help resolve With the update to 2.6.19-1.2911.fc6 and
nas-1.8-13.fc6, I retested nasd causing a kernel fault when confgiured
'normally' -- i.e., /etc/nas/nasd.conf inputsection 'autoOpen "yes"'

I began by disabling nasd at startup, and at a root console entered:

strace -f -o ~/nasd_2.6.19-1.2911.fc6_panic_autoOpen-yes.trace /usr/bin/nasd
-aa -b

When it blew up, I logged in to another TTY and did 'sync' followed by reboot.

Attached is the trace file: nasd_2.6.19-1.2911.fc6_panic_autoOpen-yes.trace

I also tested it with /etc/nas/nasd.conf 'autoOpen "no"' using the same
procedure as above but with a different trace filename.

This did not blow up exactly, but would not return a bash prompt, so again I
logged to another TTY and did sync and reboot.

Attahced is the trace file: nasd_2.6.19-1.2911.fc6_panic_autoOpen-no.trace

I hope this information is helpful. Please let me know if there is anything
else I can do to help resolve this problem. Thank you.

this problem. Thank you.

Created attachment 148225 [details]
strace log for nasd started with autoOpen 'no' in fc6

Note: Comment #10 text is double-pasted (stupid mouse!)

I think in our case it will an more an kernel bug than an nas one.
Until the kernel bug is solved, you can disable nas.

Reopen it when you have more infos.