snd_hda(freebsd 7.0 rc1) doesn't work on dell latitude D630
hey all: i can get sound from my d630. i added the snd_hda support to my kernel configure file. i can find info about my onboard sound card,but it still didn't work. pcm0: pcm0: the pciconf info about it: [EMAIL PROTECTED]:0:27:0: class=0x040300 card=0x01f91028 chip=0x284b8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801H &SUBSYS_81EC1043&REV_02\3&11583659&0&D8' class = multimedia the output from "mixer" command: $ mixer [Fri 4:32:56pm] Mixer vol is currently set to 75:75 Mixer pcm is currently set to 75:75 Mixer speaker is currently set to 75:75c Mixer line is currently set to 75:75 Mixer rec is currently set to 0:0 Recording source: mic ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: snd_hda(freebsd 7.0 rc1) doesn't work on dell latitude D630
lveax wrote: hey all: i can get sound from my d630. i added the snd_hda support to my kernel configure file. i can find info about my onboard sound card,but it still didn't work. pcm0: pcm0: the pciconf info about it: [EMAIL PROTECTED]:0:27:0: class=0x040300 card=0x01f91028 chip=0x284b8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801H &SUBSYS_81EC1043&REV_02\3&11583659&0&D8' class = multimedia the output from "mixer" command: $ mixer [Fri 4:32:56pm] Mixer vol is currently set to 75:75 Mixer pcm is currently set to 75:75 Mixer speaker is currently set to 75:75c Mixer line is currently set to 75:75 Mixer rec is currently set to 0:0 Recording source: mic ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]" I have a similar problem (also with a D630 ) ; I only get sound when plugging in a headset or similar. Sound won't work over the internal speakers. I also tried the oss drivers, without success though: at the time ( about a month ago ) it even locked up my system. [EMAIL PROTECTED] uname -a FreeBSD Rena.FStaals.net 7.0-BETA4 FreeBSD 7.0-BETA4 #0: Fri Dec 21 11:48:15 CET 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/RENAKERNEL i386 -- -Frank Staals ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: gmirror on 7B4
Quoting Clifton Royston <[EMAIL PROTECTED]>: On Wed, Jan 02, 2008 at 08:47:43AM -0800, Chris H. wrote: Quoting John Nielsen <[EMAIL PROTECTED]>: >I'm not sure I remember everything from earlier in this thread so I >don't know if it's relevant, BUT you can't boot from a gstripe volume >(or from a gconcat one AFAIK). Inferring from your fstab example >below it doesn't sound like you intend to but I just wanted to be >sure. Are you sure? I read that using gmirror requires /kernel to be located in the /boot slice and everything else (all other slices) can be mirrored safely. But in all my reading (man pages, FBSD handbook, asstd articles) I haven't seen anything indicating booting wasn't possible from a gstripe volume. Your current idea is backwards; you can boot from entirely mirrored drives (i.e. RAID1) and I've been doing it since 5.3, but AFAIK it is impossible to boot from a striped drive and I suspect will remain so for a long time. One way to visualize this is to recognize that because the gmirror information is stored at the very end of the lower-level GEOM object, each of the raw drives in the mirrored set appears to be an perfectly normal drive when reading it from its beginning; thus it is possible to simply read it as a normal device during the earlier stages of boot until GEOM and gmirror loads. With striping, however, the logical content is spread out across multiple drives, so any one drive you try to boot from has only 1/Nth of the relevant sectors. Indeed, and thank you for pointing out the obvious to me. :) I was almost immediately reminded of that after posting. :P But really, I appreciate your taking the time to /enlighten/ me. It /does/ help. Given the /wealth/ of information afforded to me here on the list, after proposing my intentions. It quickly occurred to me that I had developed quite a few misconceptions about GEOM and friends, and that I should have taken just a bit more time before leaping. In the final analysis, I think it would be /far/ more efficient if I simply blanked my current disk, and simply laid it out as I ultimately want it. Then simply unarc the root folders to their desired destinations from the most recent backups. Which kind of makes this thread a loop. As my initial question was why wasn't gMIRROR part of sysinstall. It's funny, I've spent over 2 decades running *BSD, and yet I never really spent much time obtaining intimate knowledge about the disk "construction". Oh, it's not that I know nothing about it. But rather, that once I determined the ultimate layout for my needs, I simply let sysinstall handle it. So other than needing to add disks and move/ re-create slices, I was done. But as I now revisit it, I discover I should probably spend a little more time acquainting myself with it. :) Thanks again for taking the time to respond. I appreciate it. Chris Does this help? -- Clifton -- Clifton Royston -- [EMAIL PROTECTED] / [EMAIL PROTECTED] President - I and I Computing * http://www.iandicomputing.com/ Custom programming, network design, systems and network consulting services ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- panic: kernel trap (ignored) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: gstripe on 7B4 - was: gmirror on 7B4
Quoting John Nielsen <[EMAIL PROTECTED]>: Quoting "Chris H." <[EMAIL PROTECTED]>: If you want specific advice for a specific scenario you can probably get it, but you'll have to supply some additional details. For instance I'm still not sure if this is a new install or an upgrade Both: I was wondering why gmirror wasn't an option during sysinstall (the creation, and installation to). Which begged the question - now that it's installed... (even after re-reading the entire thread), or if da3 is the same size as da0-2. Doing what you describe below will blow away the existing contents of da3 and the other disks, and/or won't be allowed if anything on da3 is currently mounted/running. Also you should stop saying mirror if you mean stripe or JBOD. :) Quite right. Again, my bad. I'm sorry this became so convoluted. It seemed so clear at first. But as it started a question about gmirror, and my almost immediate discovery that gmirror doesn't do RAID0, as I required. Turned it into gstripe. I thought I had managed to make the transition smoothly. But as you effectively indicated, no dice. Sorry. :( Thank you *very* much for your informative, and thoughtful replies - and patience. :) OK, in the final analysis I've decided (now that it's (7B4) installed...) I'll just keep /boot, /root (and presumably /dev) on the already available and running install disk (da3). Then perform: # gstripe label -v -s 131072 bigstripe \ /dev/da0 /dev/da1 /dev/da2 # newfs -U /dev/stripe/bigstripe # mkdir /bigstripe # mount /dev/stripe/bigstripe /bigstripe # echo 'geom_stripe_load="YES"' >> /boot/loader.conf # echo '/dev/stripe/bigstripe /bigstripe ufs rw 2 2' >> /etc/fstab Good up to here. Now you still have your running system and existing partitions on da3, and a new empty large raid0 volume mounted on /bigstripe. Before continuing, you should ask yourself (and perhaps tell the rest of us) what exactly do you want to use all of that space for? Sure. I simply want to utilize all the space available to me on the 2U rack system it's currently running on. It's local, so I have direct access to it. da3 is probably large enough for the OS itself, and while it's not redundant at least you have better odds of not losing your OS if a drive fails with this setup. Well, there's kind of a funny story attached to this system. I got up to stretch my legs, as I had been at the console for hours. So I went for a fairly long walk. I happened to past a couple of dumpsters during my journey and noticed a 2U rackmount system leaning against one of them. I could see it had been there for at least a 'couple of days. So now being confident that this was it's intended final resting place, I picked it up and took it back with me. As I was sure that at least /some/ of the components were salvageable. After I got it back I popped the top off of it, and had a look inside. I couldn't believe it. It had the same Tyan board that most of the servers I manage here run. Both of the CPU sockets were filled as well. So, I then took a careful look for any visible damage, and couldn't find any, nor was I able to smell that distinctive tell-tale oder that IC's, trace patterns, and such leave after failure. So I looked it over one more time before plugging it in, and discoverd that the single SIMM that was in it, was in the wrong slot. So I moved it and took a chance, plugged it in and powered it up. It POSTed as it should! Great! I just inherited a perfect system. :) It had a copy of FreeBSD-4.3 on it. But it wouldn't boot (not that I cared). So I did some more (deeper) probing, and discovered the 4 IBM SCSI drives installed in it had less than 20hrs. on them. They're brand new! WOW, with that kind of luck, I should have bought a lottery ticket. :) To the point, given the time on these drives, and my experience with IBM's line of ULTRA SCSI drives. I have little fear of failure for quite some time. I also have a backup schedule that runs no less than twice daily (immediately prior to, and immediately after build world/kernel, install kernel/world as well). So this doesn't immediately concern me. Many things are likely to change prior to my needing to get concerned about drive failure. As to keeping/wiping da3; I hadn't intended to wipe da3. But rather, move the bulk of what's already there to the newly created stripe. Then eventually (after ensuring everything works as intended) re-sizing (shrinking) it down and adding the now available "slack" to the stripe pool. # cd /var # tar cf - . | (cd /bigstripe; tar xvf - and repeating the above two lines for /bin, /compat, /dist, /entropy, /etc, /lib, /libexec, /media, /mnt, /proc, /rescue, /sbin, /sys, /tmp, and /usr That will get your files moved, but what are you trying to accomplish here? Move (mostly) everything off of da3. moving and remaking /home. Then deleting and re-creating the above (/bin, /compat, etc...). How do you propose to re-create them if they've been moved to
Linux Binary locking system
Hi, I'm sorry if this is the wrong place to report such a thing but it seems appropriate to me. I have a Linux binary which I got from *http://preview.tinyurl.com/2qwob4*. The binary works fine for a short period but after 10 minutes or so, the system will completely lock up. It won't be responsive from the keyboard or the network. Although I realize not every program will be able to run under the binary compatibility, the system locking up seems like a significant enough bug to have attention brought to it. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RELENG_7 jerky mouse and skipping sound (still a problem -BETA3)
On Fri, Jan 04, 2008 at 09:27:39PM +0100, Kris Kennaway wrote: >> OK, can you obtain a schedgraph trace when the problem is manifesting? See >> /usr/src/tools/sched/ and previous discussion in this or related threads. > > Anyone? Time is rapidly running out to get this fixed in time for > 7.0-RELEASE, so we need this trace ASAP. Sorry, I've been unable to reboot the box with this problem this week (to turn off hyperthreading, which is currently masking the problem somewhat). I'll try to do this tonight or tomorrow. Thanks, David ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Linux Binary locking system
Ross Penner wrote: Hi, I'm sorry if this is the wrong place to report such a thing but it seems appropriate to me. I have a Linux binary which I got from *http://preview.tinyurl.com/2qwob4*. The binary works fine for a short period but after 10 minutes or so, the system will completely lock up. It won't be responsive from the keyboard or the network. Although I realize not every program will be able to run under the binary compatibility, the system locking up seems like a significant enough bug to have attention brought to it. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" I'm not going to run some arbitrary linux binary on my system, so please follow up yourself with: http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug.html :) Kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RELENG_7 jerky mouse and skipping sound (still a problem -BETA3)
Kris Kennaway wrote: David E. Thiel wrote: On Sun, Dec 30, 2007 at 11:12:26PM +0100, Kris Kennaway wrote: FWIW, the problem remains for me. Still terrible performance during compiles. OK. Instead of going over all of the usual questions again, can you point me to a previous mail in which you explain your observations and test results in detail? The most recent is http://marc.info/?l=freebsd-stable&m=119428719505129&w=2, but it started way back at http://marc.info/?l=freebsd-current&m=118998090512027&w=2. I've tried a lot of stuff in between, and all I've been able to narrow it down to is that it's not a display driver issue, and that none of my swap partition is getting used, so that's not the problem. During compiles, my UP system with ULE still gets very unresponsive when compiling, sometimes taking up to 10 seconds just to draw a new terminal window. Even changing focus with the window manager can take several seconds. I'd like to provide more info, but I'm not sure what stats are useful for this particular issue. Please let me know. dmesg is at http://redundancy.redundancy.org/dmesg.txt, and kernel config is at http://redundancy.redundancy.org/DEEPTHOUGHT. Even though I'm still getting reported 80-95% memory utilization and no paging, I'm going to get an extra gig of RAM on order to see if that improves things. 2G of ram for a desktop, what's the world coming to? ;) OK, can you obtain a schedgraph trace when the problem is manifesting? See /usr/src/tools/sched/ and previous discussion in this or related threads. Anyone? Time is rapidly running out to get this fixed in time for 7.0-RELEASE, so we need this trace ASAP. Kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RELENG_7 jerky mouse and skipping sound (still a problem -BETA3)
Josh Carroll wrote: OK, can you obtain a schedgraph trace when the problem is manifesting? See /usr/src/tools/sched/ and previous discussion in this or related threads. Anyone? Time is rapidly running out to get this fixed in time for 7.0-RELEASE, so we need this trace ASAP. Kris, I would be happy to try to reproduce this and provide the necessary trace/debug info, however I admit at this point I'm not sure which set of kernel configuration and/or setup is causing the issue. As I said in a previous message, I solved the jerkiness by using moused and pointing xorg.conf to /dev/sysmouse. Shall I try with /dev/psm0 instead and provide the schedgraph info? Or is enabling PREEMPTION (which I have done in my custom kernel) already "fixing" this for me, and therefore should I use a GENERIC kernel, just substituting SCHED_4BSD with SCHED_ULE? The problems I am currently interested in are people who have not found an acceptable workaround for their performance problems :) There are outstanding reports of people for whom (as I understand it) neither scheduler performs well on UP 7.0 systems when running X, compared to the same version of X on 6.x. i.e. there seems to be some kind of regression that we need to understand and then fix. Kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RELENG_7 jerky mouse and skipping sound (still a problem -BETA3)
> > OK, can you obtain a schedgraph trace when the problem is manifesting? > > See /usr/src/tools/sched/ and previous discussion in this or related > > threads. > > Anyone? Time is rapidly running out to get this fixed in time for > 7.0-RELEASE, so we need this trace ASAP. Kris, I would be happy to try to reproduce this and provide the necessary trace/debug info, however I admit at this point I'm not sure which set of kernel configuration and/or setup is causing the issue. As I said in a previous message, I solved the jerkiness by using moused and pointing xorg.conf to /dev/sysmouse. Shall I try with /dev/psm0 instead and provide the schedgraph info? Or is enabling PREEMPTION (which I have done in my custom kernel) already "fixing" this for me, and therefore should I use a GENERIC kernel, just substituting SCHED_4BSD with SCHED_ULE? Thanks, Josh ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RELENG_7 jerky mouse and skipping sound (still a problem -BETA3)
> The problems I am currently interested in are people who have not found > an acceptable workaround for their performance problems :) Ok, good point. :) And I guess we should assume that anyone who is still having the problem has not had success with any of the workarounds. I guess ideally, out-of-the-box, either with GENERIC or GENERIC with SCHED_ULE, they should not see jerkiness, and if they do they should report it here. > There are outstanding reports of people for whom (as I understand it) > neither scheduler performs well on UP 7.0 systems when running X, > compared to the same version of X on 6.x. i.e. there seems to be some > kind of regression that we need to understand and then fix. Ahh, I'm running SMP here, so that could certainly be part of the reason just using sysmouse worked for me. Although I personally would like to know why it's jerky when using psm0, and perhaps it might help someone with a UP setup? If so, would the schedgraph info be useful? If not, I'll butt out and let someone who's still having the problem chime in. :) Josh ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RELENG_7 jerky mouse and skipping sound (still a problem -BETA3)
Josh Carroll wrote: The problems I am currently interested in are people who have not found an acceptable workaround for their performance problems :) Ok, good point. :) And I guess we should assume that anyone who is still having the problem has not had success with any of the workarounds. I guess ideally, out-of-the-box, either with GENERIC or GENERIC with SCHED_ULE, they should not see jerkiness, and if they do they should report it here. Yes. There are outstanding reports of people for whom (as I understand it) neither scheduler performs well on UP 7.0 systems when running X, compared to the same version of X on 6.x. i.e. there seems to be some kind of regression that we need to understand and then fix. Ahh, I'm running SMP here, so that could certainly be part of the reason just using sysmouse worked for me. Although I personally would like to know why it's jerky when using psm0, and perhaps it might help someone with a UP setup? If so, would the schedgraph info be useful? If not, I'll butt out and let someone who's still having the problem chime in. :) It might be, but it is just as likely to be something else. Kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RELENG_7 jerky mouse and skipping sound (still a problem -BETA3)
On Friday 04 January 2008, Kris Kennaway wrote: > Kris Kennaway wrote: > > David E. Thiel wrote: > >> On Sun, Dec 30, 2007 at 11:12:26PM +0100, Kris Kennaway wrote: > FWIW, the problem remains for me. Still terrible performance > during compiles. > >>> > >>> OK. Instead of going over all of the usual questions again, > >>> can you point me to a previous mail in which you explain your > >>> observations and test results in detail? > >> > >> The most recent is > >> http://marc.info/?l=freebsd-stable&m=119428719505129&w=2, but > >> it started way back at > >> http://marc.info/?l=freebsd-current&m=118998090512027&w=2. > >> > >> I've tried a lot of stuff in between, and all I've been able to > >> narrow it down to is that it's not a display driver issue, and > >> that none of my swap partition is getting used, so that's not > >> the problem. During compiles, my UP system with ULE still gets > >> very unresponsive when compiling, sometimes taking up to 10 > >> seconds just to draw a new terminal window. Even changing focus > >> with the window manager can take several seconds. I'd like to > >> provide more info, but I'm not sure what stats are useful for > >> this particular issue. Please let me know. dmesg is at > >> http://redundancy.redundancy.org/dmesg.txt, and kernel config is > >> at http://redundancy.redundancy.org/DEEPTHOUGHT. Even though I'm > >> still getting reported 80-95% memory utilization and no paging, > >> I'm going to get an extra gig of RAM on order to see if that > >> improves things. 2G of ram for a desktop, what's the world > >> coming to? ;) > > > > OK, can you obtain a schedgraph trace when the problem is > > manifesting? See /usr/src/tools/sched/ and previous discussion in > > this or related threads. > > Anyone? Time is rapidly running out to get this fixed in time for > 7.0-RELEASE, so we need this trace ASAP. http://am-productions.biz/docs/ktr.out.gz Is there a way to export the graph once I'm looking in it in schedgraph.py? -- Anish Mistry signature.asc Description: This is a digitally signed message part.
Re: RELENG_7 jerky mouse and skipping sound (still a problem -BETA3)
Anish Mistry wrote: On Friday 04 January 2008, Kris Kennaway wrote: Kris Kennaway wrote: David E. Thiel wrote: On Sun, Dec 30, 2007 at 11:12:26PM +0100, Kris Kennaway wrote: FWIW, the problem remains for me. Still terrible performance during compiles. OK. Instead of going over all of the usual questions again, can you point me to a previous mail in which you explain your observations and test results in detail? The most recent is http://marc.info/?l=freebsd-stable&m=119428719505129&w=2, but it started way back at http://marc.info/?l=freebsd-current&m=118998090512027&w=2. I've tried a lot of stuff in between, and all I've been able to narrow it down to is that it's not a display driver issue, and that none of my swap partition is getting used, so that's not the problem. During compiles, my UP system with ULE still gets very unresponsive when compiling, sometimes taking up to 10 seconds just to draw a new terminal window. Even changing focus with the window manager can take several seconds. I'd like to provide more info, but I'm not sure what stats are useful for this particular issue. Please let me know. dmesg is at http://redundancy.redundancy.org/dmesg.txt, and kernel config is at http://redundancy.redundancy.org/DEEPTHOUGHT. Even though I'm still getting reported 80-95% memory utilization and no paging, I'm going to get an extra gig of RAM on order to see if that improves things. 2G of ram for a desktop, what's the world coming to? ;) OK, can you obtain a schedgraph trace when the problem is manifesting? See /usr/src/tools/sched/ and previous discussion in this or related threads. Anyone? Time is rapidly running out to get this fixed in time for 7.0-RELEASE, so we need this trace ASAP. http://am-productions.biz/docs/ktr.out.gz Is there a way to export the graph once I'm looking in it in schedgraph.py? The ktr.out is all we need, thanks. Kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RELENG_7 jerky mouse and skipping sound (still a problem -BETA3)
On Sun, Dec 30, 2007 at 03:30:40PM -0800, David E. Thiel wrote: > I've tried a lot of stuff in between, and all I've been able to narrow > it down to is that it's not a display driver issue, and that none of > my swap partition is getting used, so that's not the problem. During > compiles, my UP system with ULE still gets very unresponsive when > compiling, sometimes taking up to 10 seconds just to draw a new terminal > window. Even changing focus with the window manager can take several > seconds. I'd like to provide more info, but I'm not sure what stats > are useful for this particular issue. Please let me know. I get the same type of thing, and have brought it up on the lists at some point in the past. Basically, if the x server process consumes enough CPU that it is not regarded by ULE to be an "interactive" process anymore, then it doesn't fair very well against other processes that are contending for CPU. I use Windowmaker, which normally treads pretty lightly, but I can imagine that the problem would be much easier to trigger on some other window managers. I can easily trigger it by starting xlockmore with a pretty busy screenhack with a compile running in the background. Marcus ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
