Hello,
I assume it's the place to ask my question :
is there some known reason to not enable the module alsa snd-vxpocket,
for the digigram soundcard?
Otherwise, due to its audio quality, and despite of its long life, it
should be included in the fedora kernel...
Compilation of the module from alsa 1.0.20 lib is ok.
Thanks
Thomas

Hi All,
I recently updatet my kernel first to vmlinuz-2.6.29.6-217.2.8.fc11.i586
and then to vmlinuz-2.6.29.6-217.2.16.fc11.i586 and neither of them
bootet on my system.
Currently I am back to vmlinuz-2.6.29.6-217.2.3.fc11.i586 which runs fine.
My kernel commandline looks like this: "rhgb quiet nomodeset" (mode
setting never worked right for me).
The only thing I get to see when booting one of the not working kernels
is the output of the usb probing with my mouse being the last device
found. After this the system just does nothing. It does not hang
completely though since I am able to reboot with ctrl-alt-delete. If I
press those keys, the kernel prints "md: stopping all devices" (or
something very similar) and reboots.
I thought about filling a bug, but I don't really know what to write
besides "does not boot".
Does anyone have the slightest idea what the problem might be?
Thanks,
Rolf.

When will 2.6.30 and 2.6.31 be released as updates for F11????
Why is F11 being kept at 2.6.29? That is what F11 was initially
released at, and it is still stuck at this release?
I would like to know if and when 2.6.3X will be released as an updated for F11.
MK
_________________________________________________________________
Windows Live: Keep your friends up to date with what you do online.
http://windowslive.com/Campaign/SocialNetworking?ocid=PID23285::T:WLMTAGL...

In building 2.6.29..6-217.2.8.fc11 from source rpm for i586 architecture on a machine with amd athlon64 cpu, I get this warning message:
arch/x86/kernel/pvclock.c:63:7: warning: "__x86_64__" is not defined
Thing is, I have no problems running i586 kernel, and even the resulting kernel runs fine. It appears to be an error in the code, where
#elif __x86_64__ ought to be changed to
#elif defined(__x86_64__)
Cheers,
MK
_________________________________________________________________
Get back to school stuff for them and cashback for you.
http://www.bing.com/cashback?form=MSHYCB&publ=WLHMTAG&crea=TEXT_MSHYCB_Ba...

Hi!
The internal mic does not work under Fedora 11 latest kernel
(2.6.29.6-217.2.8.fc11). People from Ubuntu [1] submitted a patch
backported from 2.6.30 since it is fixed on this version.
Could it be possible to apply it for the next fedora's kernel release?
Regards,
Manuel Bejarano.
[1] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/394793

Due to backport of patch
linux-2.6-iwl3945-report-killswitch-changes-even-if-the-interface-is-down.patch
we have bunch of iwl3945 bugs (race conditions) that are not reproducible
on vanilla 2.6.29. These patches address them (at least some of them).
[PATCH 1/3] iwl3945: release resources before shutting down (F11 backport)
Resolves RHBZ 499811 (and partially 501117), backport of upstream commit,
2.6.30 has this fix.
[PATCH 2/3] iwl3945: add debugging for wrong command queue (F11 backport)
Partially resolves RHBZ 501117. Backport of upstream commit, 2.6.30 has this
commit. Bug is still reproducible, but after patch applied system not crash.
Further work needed to fully resolve the problem, but I'm not sure is easy way
to fix 501117 (DMA related memory corruption) other than rebase driver to that
we have in 2.6.31.
[PATCH 3/3] iwl3945: fix rfkill SW and HW mishmash
Resolves RHBZ 498622. The bug is fixed in mainline from 2.6.31-rc3 due to total
rewrite of rfkill framework (commit: 19d337dff95cbf76edd3ad95c0cee2732c3e1ec5
"rfkill: rewrite"). However it is reproducible on 2.6.30 as well. Perhaps I
should post this patch against 2.6.30, but I'm not sure is such kind of
patches, which are not backports, are acceptable in stable kernel.
I tested all patches on my laptop.

I just noticed NFSv4.1 is set to "DEVELOPER ONLY" in the
mainline kernel and I wonder if there an guess as to when
this will be moved "EXPERIMENTAL"?
I was hoping to enable this in upcoming Fedora Development
builds so we can get a broader base of testing but I'm a bit
hesitant with it being a "DEVELOPER ONLY"...
Although, I have done (and will continue to do) regression testing
with this enable and have seen any problems, plus this new code
does not even come into play unless the mount command explicitly as
for it (ala -o minorversion=1) on v4 mounts... which seems to be
fairly stable...
steved.