via DRI module
Hi there, Do you know how to use via.ko in Freebsd? In my investigation, Via.ko is not ported to freebsd. right? If so, can you give some information how to port kernel module? Thanks, Minseok Choi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PR backlog
Hello Warner et all, On Wed, December 26, 2007 7:42 pm, M. Warner Losh wrote: Mark and Henrik make a number of good points here. Rather than reply to the details, I'm going to make a couple of quick observations. As a project we're not leveraging the community sufficiently when it comes to contributions. The current system of patch review and submission is very hap-hazard. If you happen to get the attention of the right person at the right time, then it goes in. If not, patches can languish a long time in the PR system. Indeed, I am one of the persons trying to find these relatively easy things which I can do along side my other projects and things, but I dont see them all (eventhough I try to keep track of them as much as possible); but what will happen is that I learn more and more about the system and at some point in time I will stop working on these easy PR's and seeking more difficult ones to fix, at that point someone else has to step up to fill in the gap that gets created; this might be a problematic part :-) Though for everyone having simple fixes, please send them to me so that I can evaluate them and (together with Warner in this case (As my mentor)) I will try to get them in as correctly and quickly as possible :-) (keeping up with the high standards of FreeBSD ofcourse). The PR system is also the wrong tool for the job. While Mark touches on the cultural issues in play, they are exacerbated by the misapplication of a problem system to be a patch submission and tracking system. Maybe we need to adopt a practice from the Linux community. At least for arm kernel patches, there is a two step process: submit it to a mailing list for review and refinement, with the second step being submitting it into a queue. I'm not sure the details we need to be successful in the FreeBSD project. Many of the USB patches in the PR system I left alone because I didn't have the time and/or knowledge to evaluate them for inclusion, or I saw something obviously wrong in the patch. When I was trying to just get through the obviously trivial patches. Warner Some things that I think need to be done by the bugbuster/bugmeister team and additional people is a constant effort to keep track of the incoming tickets; Mark does a great job at that, and I try to helpout as much as possible there, but we are all busy every now and then and then a backlog on processing the incoming tickets gets created and we loose the battle :-) This is where you (the reader) can get in and try to help us with that, so that we can properly assign the tickets, and try to keep track of them so that they can get resolved as soon as possible. Though, some complains are that we are not fast enough etc, I think we need to make sure that everyone keeps understanding that we are a Voluntary project, and that we have resources at unknown times and dates, a committer can be active the one day, and remain inactive the rest of the week; that's a side effect on the project being based on volunteers; we did a good job so far with that, but every now and then something slips in between. What we should do at that point is not ranting around as I see happen sometimes, but instead try to get the bugbusters / bugmeister team involved so that we can see what other options are available, sometimes we can succeed in and sometimes we cannot; but dont keep the problem to yourself and the assigned person because that might not work :-) Just my E 0,02 :-) -- /\ Best regards, | [EMAIL PROTECTED] \ / Remko Lodder | [EMAIL PROTECTED] Xhttp://www.evilcoder.org/ | / \ ASCII Ribbon Campaign | Against HTML Mail and News ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 7.0-BETA4 and msk problems
On Mon, Dec 10, 2007 at 11:03:47AM +0200, Danny Braniss wrote: On Sun, Dec 09, 2007 at 02:41:28PM +0200, Danny Braniss wrote: with this onboard NIC (LOB?) mskc0: Marvell Yukon 88E8056 Gigabit Ethernet e1000phy0: Marvell 88E1149 Gigabit PHY PHY 0 on miibus0 [EMAIL PROTECTED]:1:0:0: class=0x02 card=0x81f81043 chip=0x436411ab rev=0x12 hdr=0x00 vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' device = '88E8056 Yukon PCI-E Gigabit Ethernet Controller' class = network subclass = ethernet I'm getting allot of: msk0: watchdog timeout and mskc0: Tx descriptor error and msk0: link state changed to DOWN and msk0: link state changed to UP any help is most welcome, danny It seems that the issue happens only on 88E8056/88E1149 PHY. See PR 116853 and 114631. Sorry, I have no cluet yet. to add some more noise, this is the first host that panicked too :-) anything I can do to help? Probably ship the hardware to me? :) love to, but the hardware is not mine :-) here is some more info, this is a different board, but with the same Marvell 88E8056, and it panics after printing 'no PHY found!' and the ethernet is -1 (ff.ff...) danny ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PR backlog
On середа 26 грудень 2007, M. Warner Losh wrote: = As a project we're not leveraging the community sufficiently when it = comes to contributions. The current system of patch review and = submission is very hap-hazard. If you happen to get the attention of = the right person at the right time, then it goes in. If not, patches = can languish a long time in the PR system. This is /generally/ true, and has been for years. However, the USB-part of FreeBSD is in a /particularly/ bad shape, so something USB-specific may be in order. There is talk about a whole new USB reimplementation, and somebody is working in the Perforce nirvana-land on it. Maybe, that work needs a closer look by other experts so as to bring it to the FreeBSD masses faster... -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PR backlog
In message: [EMAIL PROTECTED] Mikhail Teterin [EMAIL PROTECTED] writes: : On середа 26 грудень 2007, M. Warner Losh wrote: : = As a project we're not leveraging the community sufficiently when it : = comes to contributions. �The current system of patch review and : = submission is very hap-hazard. �If you happen to get the attention of : = the right person at the right time, then it goes in. �If not, patches : = can languish a long time in the PR system. : : This is /generally/ true, and has been for years. However, the USB-part of : FreeBSD is in a /particularly/ bad shape, so something USB-specific may be in : order. Usually that's called a maintainer, but we haven't had a real one in a long time. Or even a fake one. That's what it would take to solve the problem. : There is talk about a whole new USB reimplementation, and somebody is : working in the Perforce nirvana-land on it. Maybe, that work needs a closer : look by other experts so as to bring it to the FreeBSD masses faster... Now you are being insulting here. There are people looking at Hans' new stack, and have identified a few issues with it. Hans' is working on the issues identified, and even provides snapshots from time to time for people to try. Warner ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Atheros AR5007EG ath_hal STATUS 13
Hi, I have an Acer Aspire 4520 laptop, my atheros wifi is detected but I got ath_hal status 13. Any chance to make this wifi card working under FreeBSD-7.0/AMD64? Thanks in advance. -- Jimmy B. Lim j i m m y b l i m @ g m a i l . c o m ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
USB issues (not just Re: PR backlog)
четвер 27 грудень 2007 10:52 до, M. Warner Losh Ви написали: Usually that's called a maintainer, but we haven't had a real one in a long time. Or even a fake one. Well, you responded to me earlier suggesting, I take it upon myself to merge USB-advancements from 7.x to 6.x. That implied, somebody did something for 7.x, did not it? Can that body (whoever they are) not put on the vacant USB-maintainer hat and push the fixes/improvements into 6.x (preferably -- before the 6.3 is released unto the world)? If not that same person, then, maybe, the people, whom you mention below as looking at Hans' new stack, can do the merging? : There is talk about a whole new USB reimplementation, and somebody is : working in the Perforce nirvana-land on it. Maybe, that work needs a : closer look by other experts so as to bring it to the FreeBSD masses : faster... Now you are being insulting here. There are people looking at Hans' new stack, and have identified a few issues with it. Hans' is working on the issues identified, and even provides snapshots from time to time for people to try. I sure hope, you were joking about the insulting part. I don't see anything in my words, that's in any way disparaging or insulting. What troubles me, however, is that this new work is being done in that ivory tower called perforce. Nothing against that particular revision-control system, but the FreeBSD work in perforce in the past tended to take /years/ to be merged into the project's official repository -- CVS. Probably, because the actual development is far more thrilling, than the mundane merging from on repository to another... But if somebody is, indeed, working on a new USB stack, that's terrific news. It also implies, we might get a USB-maintainer some time soon. I just want it soon/er/, because it has been far too long already... I am with FreeBSD since early ninetees (and don't need refreshers on how we are a volunteer project). But I can't remember another case of a subsystem being so broken for so long -- through so many releases. -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB issues (not just Re: PR backlog)
In message: [EMAIL PROTECTED] Mikhail Teterin [EMAIL PROTECTED] writes: : четвер 27 грудень 2007 10:52 до, M. Warner Losh Ви написали: : Usually that's called a maintainer, but we haven't had a real one in a : long time. Or even a fake one. : : Well, you responded to me earlier suggesting, I take it upon myself to merge : USB-advancements from 7.x to 6.x. That implied, somebody did something for : 7.x, did not it? Can that body (whoever they are) not put on the vacant : USB-maintainer hat and push the fixes/improvements into 6.x (preferably -- : before the 6.3 is released unto the world)? If not that same person, then, : maybe, the people, whom you mention below as looking at Hans' new stack, : can do the merging? I did the bulk of the work for the 7.0 stuff, at least getting things into the tree. Since I did the work, my last job got totally insane and then I switched jobs. I don't have the time needed to do this. : But if somebody is, indeed, working on a new USB stack, that's : terrific news. It also implies, we might get a USB-maintainer some : time soon. I just want it soon/er/, because it has been far too long : already... We can all agree that this is long overdue. But we need to make sure of a few critical details so we don't create another mess for ourselves down the line. Warner ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB issues (not just Re: PR backlog)
четвер 27 грудень 2007 12:33 по, M. Warner Losh Ви написали: I did the bulk of the work for the 7.0 stuff, at least getting things into the tree. Since I did the work, my last job got totally insane and then I switched jobs. As the old Russian saying went: if vodka interferes with your job, you have to stop working. We can all agree that this is long overdue. But we need to make sure of a few critical details so we don't create another mess for ourselves down the line. Seriosly, thank you and do get back to it whenever you can. -mi ## The information contained in this communication is confidential and may contain information that is privileged or exempt from disclosure under applicable law. If you are not a named addressee, please notify the sender immediately and delete this email from your system. If you have received this communication, and are not a named recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. ## ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
portaudit and portsnap acting silly.
Portaudit does this: # portaudit -Fa auditfile.tbz 100% of 46 kB 6001 kBps portaudit: Database too old. Old database restored. portaudit: Download failed. Portsnap does this: # portsnap fetch Looking up portsnap.FreeBSD.org mirrors... 4 mirrors found. Fetching snapshot tag from portsnap3.FreeBSD.org... done. Latest snapshot on server is older than what we already have! Cowardly refusing to downgrade from Thu Dec 27 08:10:58 PST 2007 to Mon Dec 3 17:04:28 PST 2007. In case anyone knows anyone who can beat them back into submission. Dave Overton, Owner SYIX.COM [EMAIL PROTECTED] (530) 755-1751 x101 Fax (530) 751-8871 800-988-SYIX ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Instant Reboot with 7.0 BETA4 LifeFS Disk
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Seth Hieronymus wrote: In testing my Windows desktop with the 7.0 LiveFS disk ( 7.0-BETA4-amd64-livefs.iso), I get an instant reboot when the CD is run. As far as I can tell, no console messages are printed, so it seems the error happens very early in the loading process. Other FreeBSD versions (6.2, i386 7.0) also exhibit the same behavior. If left alone, the computer will just continually reboot. The specs of the system are: Soltek SL-k8TPro-939 (Via K8T800 Pro ATX) motherboard AMD Athlon64 3800+ Newcastle 2.4GHz Promise FastTrak 579 RAID Controller (PDC20579) 2x Seagate Barracuda 7200 SATA 150 disks in RAID 1 Re-badged Radeon 9600 Pro 256MB 128-bit DDR AGP video card My guess is that the disk controller is not supported. Should this cause an instant reboot with a live filesystem disk? Is there anyway to debug this since no console messages are printed? One guess: what if you disable and disconnect your hard disk? This will be helpful to narrow down the issue... Cheers, - -- Xin LI [EMAIL PROTECTED] http://www.delphij.net/ FreeBSD - The Power to Serve! -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHdDE0hcUczkLqiksRAnqZAJ9d5DvreJwI/gciL+xtBcone7uhuACfbakl p/pv89ZWt25HGL9I/4a8avU= =RApP -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: portaudit and portsnap acting silly.
On Thu, Dec 27, 2007 at 11:22:18AM -0800, Dave Overton wrote: Portaudit does this: # portaudit -Fa auditfile.tbz 100% of 46 kB 6001 kBps portaudit: Database too old. Old database restored. portaudit: Download failed. Portsnap does this: # portsnap fetch Looking up portsnap.FreeBSD.org mirrors... 4 mirrors found. Fetching snapshot tag from portsnap3.FreeBSD.org... done. Latest snapshot on server is older than what we already have! Cowardly refusing to downgrade from Thu Dec 27 08:10:58 PST 2007 to Mon Dec 3 17:04:28 PST 2007. In case anyone knows anyone who can beat them back into submission. Are you using a proxy server. I encountered similar problems with a proxy. In fact I usually set up squid not to cache portsnap[0-9].freebsd.org. Never seen such a problem with portaudit though... Hope this helps. -- Guido Falsi [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Instant Reboot with 7.0 BETA4 LifeFS Disk
On Dec 27, 2007 4:11 PM, Xin LI [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Seth Hieronymus wrote: In testing my Windows desktop with the 7.0 LiveFS disk ( 7.0-BETA4-amd64-livefs.iso), I get an instant reboot when the CD is run. As far as I can tell, no console messages are printed, so it seems the error happens very early in the loading process. Other FreeBSD versions (6.2, i386 7.0) also exhibit the same behavior. If left alone, the computer will just continually reboot. The specs of the system are: Soltek SL-k8TPro-939 (Via K8T800 Pro ATX) motherboard AMD Athlon64 3800+ Newcastle 2.4GHz Promise FastTrak 579 RAID Controller (PDC20579) 2x Seagate Barracuda 7200 SATA 150 disks in RAID 1 Re-badged Radeon 9600 Pro 256MB 128-bit DDR AGP video card My guess is that the disk controller is not supported. Should this cause an instant reboot with a live filesystem disk? Is there anyway to debug this since no console messages are printed? One guess: what if you disable and disconnect your hard disk? This will be helpful to narrow down the issue... Cheers, - -- Xin LI [EMAIL PROTECTED]http://www.delphij.net/ FreeBSD - The Power to Serve! -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHdDE0hcUczkLqiksRAnqZAJ9d5DvreJwI/gciL+xtBcone7uhuACfbakl p/pv89ZWt25HGL9I/4a8avU= =RApP -END PGP SIGNATURE- Thanks for the response! What you suggested worked -- I removed the SATA cables from both harddrives, and then was able to boot using the 7.0 BETA4 AMD64 LiveFS cd. It appears that the disk controller is not the problem. It is recognized by FreeBSD as (hand copied): atapci0: Promise PDC20579 SATA150 controller port 0xd200-0xd27f,0xd300-0xd3ff mem 0xf8236000-0xf8236fff,0xf820-0xf821 irq 19 at device 9.0 on pci0 Searching the dmesg, there are no other devices on irq 19. Not sure it matters, but one interesting thing is that the motherboard also has another SATA controller (irq 20 at device 15.0), which is: atapci1: VIA 6420 SATA150 controller Any ideas? Thanks, Seth ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Instant Reboot with 7.0 BETA4 LifeFS Disk
On Thu, Dec 27, 2007 at 04:49:47PM -0700, Seth Hieronymus wrote: The specs of the system are: Soltek SL-k8TPro-939 (Via K8T800 Pro ATX) motherboard AMD Athlon64 3800+ Newcastle 2.4GHz Promise FastTrak 579 RAID Controller (PDC20579) 2x Seagate Barracuda 7200 SATA 150 disks in RAID 1 Re-badged Radeon 9600 Pro 256MB 128-bit DDR AGP video card One guess: what if you disable and disconnect your hard disk? This will be helpful to narrow down the issue... Thanks for the response! What you suggested worked -- I removed the SATA cables from both harddrives, and then was able to boot using the 7.0 BETA4 AMD64 LiveFS cd. Not sure it matters, but one interesting thing is that the motherboard also has another SATA controller (irq 20 at device 15.0), which is: atapci1: VIA 6420 SATA150 controller I've got two disks attached in RAID1 to the VIA 6420 controller. Works fine here (7.0-BETA3 FreeBSD amd64). Try connecting your disks to the via controller. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpxfdw6BtCYy.pgp Description: PGP signature
Failure of gvinum after panic
Hi all, I have some problems with my gvinum setup after the system panic'ed. Afterwards the system fails finding the plexes to the subdisks (or at least that is what I can understand after having searched the gvinum source code for the error string in the DMESG log..) The machine is an IBM Netfinity 5000 and the internal HW self tests does not find any errors in the hw. Luckily my root is not on a gvinum drive, so I am able to boot the server in single user. Does anyone have any hints as to what I can do to get gvinum to recognize the disks correctly? The system is 6.3 stable Dont worry about the media disks or anything right now - I am trying to revive the system disks for now. Thanks Nikolaj Hansen 7 drives: D elben State: up /dev/da1s1h A: 0/7825 MB (0%) D donau State: up /dev/da0s1h A: 0/7825 MB (0%) D raid5_4_ad11 State: up /dev/ad11 A: 6/194480 MB (0%) D raid5_3_ad10 State: up /dev/ad10 A: 6/194480 MB (0%) D raid5_2_ad9 State: up /dev/ad9A: 6/194480 MB (0%) D raid5_1_ad8 State: up /dev/ad8A: 6/194480 MB (0%) D spree State: up /dev/ad4a A: 3/114473 MB (0%) 6 volumes: V data01State: up Plexes: 1 Size:111 GB V usr State: up Plexes: 0 Size: 0 B V home State: up Plexes: 0 Size: 0 B V tmp State: up Plexes: 0 Size: 0 B V var State: up Plexes: 0 Size: 0 B V media State: up Plexes: 1 Size:379 GB 10 plexes: P data01.p0 C State: up Subdisks: 1 Size:111 GB P usr.p1 C State: up Subdisks: 0 Size: 0 B P home.p1 C State: up Subdisks: 0 Size: 0 B P tmp.p1 C State: up Subdisks: 0 Size: 0 B P var.p1 C State: up Subdisks: 0 Size: 0 B P usr.p0 C State: up Subdisks: 0 Size: 0 B P home.p0 C State: up Subdisks: 0 Size: 0 B P tmp.p0 C State: up Subdisks: 0 Size: 0 B P var.p0 C State: up Subdisks: 0 Size: 0 B P media.p0 R5 State: degraded Subdisks: 3 Size:379 GB 13 subdisks: S data01.p0.s0 State: up D: spreeSize:111 GB S usr.p1.s0 State: up D: elbenSize: 5625 MB S home.p1.s0State: up D: elbenSize: 1000 MB S tmp.p1.s0 State: up D: elbenSize:600 MB S var.p1.s0 State: up D: elbenSize:600 MB S usr.p0.s0 State: up D: donauSize: 5625 MB S home.p0.s0State: up D: donauSize: 1000 MB S tmp.p0.s0 State: up D: donauSize:600 MB S var.p0.s0 State: up D: donauSize:600 MB S media.p0.s0 State: up D: raid5_1_ad8 Size:189 GB S media.p0.s1 State: up D: raid5_2_ad9 Size:189 GB S media.p0.s2 State: staleD: raid5_3_ad10 Size:189 GB S media.p0.s3 State: up D: raid5_4_ad11 Size:189 GB Copyright (c) 1992-2007 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 is a registered trademark of The FreeBSD Foundation. FreeBSD 6.2-RELEASE-p6 #0: Wed Jul 18 23:33:58 CEST 2007 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/KERNEL_6_2 Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Pentium III/Pentium III Xeon/Celeron (498.67-MHz 686-class CPU) Origin = GenuineIntel Id = 0x673 Stepping = 3 Features=0x387fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,PN,MMX,FXSR,SSE real memory = 536854528 (511 MB) avail memory = 515715072 (491 MB) ACPI APIC Table: IBMSERMOHIC FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 1 cpu1 (AP): APIC ID: 0 MADT: Forcing active-low polarity and level trigger for SCI ioapic0 Version 1.1 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: IBM SERMOHIC on motherboard acpi0: Power Button (fixed) Timecounter ACPI-safe frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0xfe88-0xfe8b on acpi0 cpu0: ACPI CPU on acpi0 cpu1: ACPI CPU on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 skc0: 3Com 3C940 Gigabit Ethernet port 0x2000-0x20ff mem 0xfebfc000-0xfebf irq 18 at device 1.0 on pci0 skc0: 3Com Gigabit NIC (3C2000) rev. (0x1) sk0: Marvell Semiconductor, Inc. Yukon on skc0 sk0: Ethernet
Re: Packet loss every 30.999 seconds
On Sat, 22 Dec 2007, Mark Fullmer wrote: On Dec 22, 2007, at 12:08 PM, Bruce Evans wrote: I still don't understand the original problem, that the kernel is not even preemptible enough for network interrupts to work (except in 5.2 where Giant breaks things). Perhaps I misread the problem, and it is actually that networking works but userland is unable to run in time to avoid packet loss. The test is done with UDP packets between two servers. The em driver is incrementing the received packet count correctly but the packet is not making it up the network stack. If the application was not servicing the socket fast enough I would expect to see the dropped due to full socket buffers (udps_fullsock) counter incrementing, as shown by netstat -s. I couldn't see any sign of PREEMPTION not working in 6.3-PREREALEASE. em seemed to keep up with the maximum rate that I can easily generate (640 kpps with tiny udp packets), though it cannot transmit at more than 400 kpps on the same hardware. This is without aby syncer activity to cause glitches. The rest of the system couldn't keep up, and with my normal configuration of net.isr.direct=1, systat -ip (udps_fullsock) showed too many packets being dropped, but all the numbers seemed to add up right. (I didn't do end-to-end packet counts. I'm using ttcp to send and receive packets; the receiver loses so many packets that it rarely terminates properly, and when it does terminate it always shows many dropped.) However, with net.isr.direct=0, packets are dropped with no sign of the problem except a reduced count of good packets in systat -ip. Packet rate counter net.isr.direct=1 net.isr.direct=0 --- netstat -I 639042643522 (faster later) systat -ip (total rx) 639042382567 (dropped many b4 here) (UDP total) 639042382567 (udps_fullsock) 29891170340 (diff of prev 2) 340031312227 (300+k always dropped) net.isr.count small large (seems to be correct 643k) net.isr.directedlarge (correct?) no change net.isr.queued 0 0 net.isr.drop0 0 net.isr.direct=0 is apparently causing dropped packets without even counting them. However, the drop seems to be below the netisr level. More worryingly, with full 1500-byte packets (1472 data + 28 UDP header), packets can be sent at a rate of 76 kpps (nearly 950 Mbps) with a load of only 80% on the receiver, yet the ttcp receiver still drops about 1000 pps due top socket buffer full. With net.usr.direct=0 it drops an additinal 700 pps due to this. Glitches from sync(2) taking 25 ms increase the loss by about 1000 packets, and using rtprio for the ttcp receiver doesn't seem to help at all. In previous mail, you (Mark) wrote: # With FreeBSD 4 I was able to run a UDP data collector with rtprio set, # kern.ipc.maxsockbuf=2048, then use setsockopt() with SO_RCVBUF # in the application. If packets were dropped they would show up # with netstat -s as dropped due to full socket buffers. # # Since the packet never makes it to ip_input() I no longer have # any way to count drops. There will always be corner cases where # interrupts are lost and drops not accounted for if the adapter # hardware can't report them, but right now I've got no way to # estimate any loss. I tried using SO_RCVBUF in ttcp (it's an old version of ttcp that doesn't have an option for this). With the default kern.ipc.maxsockbuf of 256K, this didn't seem to help. 20MB should work better :-) but I didn't try that. I don't understand how fast the socket buffer fills up and would have thought that 256K was enough for tiny packets but not for 1500-byte packets. Their seems to be a general problem that 1Gbps NICs have or should have rings of size = 256 or 512 so that they aren't forced to drop packets when their interrupt handler has a reasonable but larger latency, yet if we actually use this feature then we flood the upper layers with hundreds of packets and fill up socket buffers etc. there. Bruce ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Instant Reboot with 7.0 BETA4 LifeFS Disk
On Dec 27, 2007 5:29 PM, Roland Smith [EMAIL PROTECTED] wrote: On Thu, Dec 27, 2007 at 04:49:47PM -0700, Seth Hieronymus wrote: The specs of the system are: Soltek SL-k8TPro-939 (Via K8T800 Pro ATX) motherboard AMD Athlon64 3800+ Newcastle 2.4GHz Promise FastTrak 579 RAID Controller (PDC20579) 2x Seagate Barracuda 7200 SATA 150 disks in RAID 1 Re-badged Radeon 9600 Pro 256MB 128-bit DDR AGP video card One guess: what if you disable and disconnect your hard disk? This will be helpful to narrow down the issue... Thanks for the response! What you suggested worked -- I removed the SATA cables from both harddrives, and then was able to boot using the 7.0BETA4 AMD64 LiveFS cd. Not sure it matters, but one interesting thing is that the motherboard also has another SATA controller (irq 20 at device 15.0), which is: atapci1: VIA 6420 SATA150 controller I've got two disks attached in RAID1 to the VIA 6420 controller. Works fine here (7.0-BETA3 FreeBSD amd64). Try connecting your disks to the via controller. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/http://www.xs4all.nl/%7Ersmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) Thanks for the reply. That's good to know about the VIA controller. I'm not quite ready to wipe my current disks yet, which I think I would have to do to switch RAID controllers, but may go that route in the future. I also confirmed I can install on a plain IDE harddrive, so may just do that for immediate testing. Thanks, Seth ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Packet loss every 30.999 seconds
On Fri, 28 Dec 2007, Bruce Evans wrote: In previous mail, you (Mark) wrote: # With FreeBSD 4 I was able to run a UDP data collector with rtprio set, # kern.ipc.maxsockbuf=2048, then use setsockopt() with SO_RCVBUF # in the application. If packets were dropped they would show up # with netstat -s as dropped due to full socket buffers. # # Since the packet never makes it to ip_input() I no longer have # any way to count drops. There will always be corner cases where # interrupts are lost and drops not accounted for if the adapter # hardware can't report them, but right now I've got no way to # estimate any loss. I tried using SO_RCVBUF in ttcp (it's an old version of ttcp that doesn't have an option for this). With the default kern.ipc.maxsockbuf of 256K, this didn't seem to help. 20MB should work better :-) but I didn't try that. I've now tried this. With kern.ipc.maxsockbuf=2048 (~20MB) an SO_RCVBUF of 0x100 (16MB), the socket buffer full lossage increases from ~300 kpps (~47%) to ~450 kpps (70%) with tiny packets. I think this is caused by most accesses to the larger buffer being cache misses -- since the system can't keep up, cache misses make it worse). However, with 1500-byte packets, the larger buffer reduces the lossage from 1 kpps in 76 kpps to precisely zero pps, at a cost of only a small percentage of system overhead (~20Idle to ~18%Idle). The above is with net.isr.direct=1. With net.isr.direct=0, the loss is too small to be obvious and is reported as 0, but I don't trust the report. ttcp's packet counts indicate losses of a few per million with direct=0 but none with direct=1. while :; do sync; sleep 0.1 in the background causes a loss of about 100 pps with direct=0 and a smaller loss with direct=1. Running the ttcp receiver at rtprio 0 doesn't make much difference to the losses. Bruce ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: VIA DRM on FreeBSD
Hi, I also have a VIA Unichrome graphics chip in one of my computers and would like to use DRM with it, but it's not possible yet. I have asked Eric Anholt about it, and here's his reply (copy--paste): - VIA DRM isn't ported. You would need to port it if you wanted DRI. - ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 7.0-BETA4 and msk problems
On Thu, Dec 27, 2007 at 12:51:29PM +0200, Danny Braniss wrote: On Mon, Dec 10, 2007 at 11:03:47AM +0200, Danny Braniss wrote: On Sun, Dec 09, 2007 at 02:41:28PM +0200, Danny Braniss wrote: with this onboard NIC (LOB?) mskc0: Marvell Yukon 88E8056 Gigabit Ethernet e1000phy0: Marvell 88E1149 Gigabit PHY PHY 0 on miibus0 [EMAIL PROTECTED]:1:0:0: class=0x02 card=0x81f81043 chip=0x436411ab rev=0x12 hdr=0x00 vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' device = '88E8056 Yukon PCI-E Gigabit Ethernet Controller' class = network subclass = ethernet I'm getting allot of: msk0: watchdog timeout and mskc0: Tx descriptor error and msk0: link state changed to DOWN and msk0: link state changed to UP any help is most welcome, danny It seems that the issue happens only on 88E8056/88E1149 PHY. See PR 116853 and 114631. Sorry, I have no cluet yet. to add some more noise, this is the first host that panicked too :-) anything I can do to help? Probably ship the hardware to me? :) love to, but the hardware is not mine :-) here is some more info, this is a different board, but with the same Marvell 88E8056, and it panics after printing 'no PHY found!' and the ethernet is -1 (ff.ff...) Hmm, I can't reproduce the panic with 88E8053 on my box. What do you mean the ethernet is -1? Sorry I didn't understand it. If PHY was not found in phy probe msk wouldn't be attached to your hardware. Would you show me backtrace information? It seems that there are several 88E8056 controllers with different revision numbers. Recent 88E8056 models doesn't seem to work but I have no clue yet. The common factor was 88E8056/88E1149 PHY. -- Regards, Pyun YongHyeon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Packet loss every 30.999 seconds
On Fri, 28 Dec 2007, Bruce Evans wrote: On Fri, 28 Dec 2007, Bruce Evans wrote: In previous mail, you (Mark) wrote: # With FreeBSD 4 I was able to run a UDP data collector with rtprio set, # kern.ipc.maxsockbuf=2048, then use setsockopt() with SO_RCVBUF # in the application. If packets were dropped they would show up # with netstat -s as dropped due to full socket buffers. # # Since the packet never makes it to ip_input() I no longer have # any way to count drops. There will always be corner cases where # interrupts are lost and drops not accounted for if the adapter # hardware can't report them, but right now I've got no way to # estimate any loss. I found where drops are recorded for the net.isr.direct=0 case. It is in net.inet.ip.intr_queue.drops. The netisr subsystem just calls IF_HANDOFF(), and IF_HANDOFF() calls _IF_DROP() if the queue fills up. _IF_DROP(ifq) just increments ifq-ip_drops. The usual case for netisrs is for the queue to be ipintrq for NETISR_IP. The following details don't help: - drops for input queues don't seem to be displayed by any utilities (except ones for ipintrq are displayed primitively by sysctl net.inet.ip.intr_queue_drops). netstat and systat only display drops for send queues and ip frags. - the netisr subsystem's drop count doesn't seem to be displayed by any utilities except sysctl. It only counts drops due to there not being a queue; other drops are counted by _IF_DROP() in the per-queue counter. Users have a hard time integrating all these primitively displayed drop counts with other error counters. - the length of ipintrq defaults to the default ifq length of ipqmaxlen = IPQ_MAXLEN = 50. This is inadequate if there is just one NIC in the system that has an rx ring size of = slightly less than 50. But 1 Gbps NICs should have an rx ring size of 256 or 512 (I think the size is 256 for em; it is 256 for bge due to bogus configuration of hardware that can handle it being 512). If the larger hardware rx ring is actually used, then ipintrq drops are almost ensured in the direct=0 case, so using the larger h/w ring is worse than useless (it also increases cache misses). This is for just one NIC. This problem is often limited by handling rx packets in small bursts, at a cost of extra overhead. Interrupt moderation increases it by increasing burst sizes. This contrasts with the handling of send queues. Send queues are per-interface and most drivers increase the default length from 50 to their ring size (-1 for bogus reasons). I think this is only an optimization, while a similar change for rx queues is important for avoiding packet loss. For send queues, the ifq acts mainly as a primitive implementation of watermarks. I have found that tx queue lengths need to be more like 5000 than 50 or 500 to provide enough buffering when applications are delayed by other applications or just by sleeping until the next clock tick, and use tx queues of length ~2 (a couple of clock ticks at HZ = 100), but now think queue lengths should be restricted to more like 50 since long queues cannot fit in L2 caches (not to mention they are bad for latency). The length of ipintrq can be changed using sysctl net.inet.ip.intrq_queue_maxlen. Changing it from 50 to 1024 turns most or all ipintrq drops into socket buffer full drops (640 kpps input packets and 434 kpps socket buffer fulls with direct=0; 640 kpps input packets and 324 kpps socket buffer fulls with direct=1). Bruce ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Failure of gvinum after panic
A little more info on the config and how it should be: current config dump: # Vinum configuration of , saved at Fri Dec 28 07:31:54 2007 drive elben device /dev/da1s1h drive donau device /dev/da0s1h drive raid5_4_ad11 device /dev/ad11 drive raid5_3_ad10 device /dev/ad10 drive raid5_2_ad9 device /dev/ad9 drive raid5_1_ad8 device /dev/ad8 drive spree device /dev/ad4a volume data01 volume usr volume home volume tmp volume var volume media plex name data01.p0 org concat vol data01 plex name usr.p1 org concat plex name home.p1 org concat plex name tmp.p1 org concat plex name var.p1 org concat plex name usr.p0 org concat plex name home.p0 org concat plex name tmp.p0 org concat plex name var.p0 org concat plex name media.p0 org raid5 1024s vol media sd name data01.p0.s0 drive spree len 234434560s driveoffset 265s plex data01.p0 plexoffset 0s sd name usr.p1.s0 drive elben len 11521427s driveoffset 4505865s sd name home.p1.s0 drive elben len 2048000s driveoffset 2457865s sd name tmp.p1.s0 drive elben len 1228800s driveoffset 1229065s sd name var.p1.s0 drive elben len 1228800s driveoffset 265s sd name usr.p0.s0 drive donau len 11521427s driveoffset 4505865s sd name home.p0.s0 drive donau len 2048000s driveoffset 2457865s sd name tmp.p0.s0 drive donau len 1228800s driveoffset 1229065s sd name var.p0.s0 drive donau len 1228800s driveoffset 265s sd name media.p0.s0 drive raid5_1_ad8 len 398282752s driveoffset 265s plex media.p0 plexoffset 0s sd name media.p0.s1 drive raid5_2_ad9 len 398282752s driveoffset 265s plex media.p0 plexoffset 1024s sd name media.p0.s2 drive raid5_3_ad10 len 398282752s driveoffset 265s plex media.p0 plexoffset 2048s sd name media.p0.s3 drive raid5_4_ad11 len 398282752s driveoffset 265s How the plexes should read out: P usr.p1 C State: up Subdisks: 1 Size: 5625 MB P home.p1 C State: up Subdisks: 1 Size: 1000 MB P tmp.p1 C State: up Subdisks: 1 Size:600 MB P var.p1 C State: up Subdisks: 1 Size:600 MB P usr.p0 C State: up Subdisks: 1 Size: 5625 MB P home.p0 C State: up Subdisks: 1 Size: 1000 MB P tmp.p0 C State: up Subdisks: 1 Size:600 MB P var.p0 C State: up Subdisks: 1 Size:600 MB The way it reads out: P usr.p1 C State: up Subdisks: 0 Size: 0 B P home.p1 C State: up Subdisks: 0 Size: 0 B P tmp.p1 C State: up Subdisks: 0 Size: 0 B P var.p1 C State: up Subdisks: 0 Size: 0 B P usr.p0 C State: up Subdisks: 0 Size: 0 B P home.p0 C State: up Subdisks: 0 Size: 0 B P tmp.p0 C State: up Subdisks: 0 Size: 0 B P var.p0 C State: up Subdisks: 0 Size: 0 B The difference is obvious - somehow gvinum lost track of the plex to subdisk relations. Is there any way of restoring these? What would happen if I where to re-create the Plexes? (Drop/create) and then saveconfig? Thanks Nikolaj Hansen On Dec 28, 2007 2:06 AM, Nikolaj Hansen [EMAIL PROTECTED] wrote: Hi all, I have some problems with my gvinum setup after the system panic'ed. Afterwards the system fails finding the plexes to the subdisks (or at least that is what I can understand after having searched the gvinum source code for the error string in the DMESG log..) The machine is an IBM Netfinity 5000 and the internal HW self tests does not find any errors in the hw. Luckily my root is not on a gvinum drive, so I am able to boot the server in single user. Does anyone have any hints as to what I can do to get gvinum to recognize the disks correctly? The system is 6.3 stable Dont worry about the media disks or anything right now - I am trying to revive the system disks for now. Thanks Nikolaj Hansen 7 drives: D elben State: up /dev/da1s1h A: 0/7825 MB (0%) D donau State: up /dev/da0s1h A: 0/7825 MB (0%) D raid5_4_ad11 State: up /dev/ad11 A: 6/194480 MB (0%) D raid5_3_ad10 State: up /dev/ad10 A: 6/194480 MB (0%) D raid5_2_ad9 State: up /dev/ad9A: 6/194480 MB (0%) D raid5_1_ad8 State: up /dev/ad8A: 6/194480 MB (0%) D spree State: up /dev/ad4a A: 3/114473 MB (0%) 6 volumes: V data01State: up Plexes: 1 Size:111 GB V usr State: up Plexes: 0 Size: 0 B V home State: up Plexes: 0 Size: 0 B V tmp State: up Plexes: 0 Size: 0 B V var State: up Plexes: 0 Size: 0 B V media
Re: PR backlog
On Thu, 27 Dec 2007 09:43:08 +0100 (CET) Remko Lodder [EMAIL PROTECTED] wrote: Hello Warner et all, On Wed, December 26, 2007 7:42 pm, M. Warner Losh wrote: Mark and Henrik make a number of good points here. Rather than reply to the details, I'm going to make a couple of quick observations. As a project we're not leveraging the community sufficiently when it comes to contributions. The current system of patch review and submission is very hap-hazard. If you happen to get the attention of the right person at the right time, then it goes in. If not, patches can languish a long time in the PR system. Indeed, I am one of the persons trying to find these relatively easy things which I can do along side my other projects and things, but I dont see them all (eventhough I try to keep track of them as much as possible); but what will happen is that I learn more and more about the system and at some point in time I will stop working on these easy PR's and seeking more difficult ones to fix, at that point someone else has to step up to fill in the gap that gets created; this might be a problematic part :-) Though for everyone having simple fixes, please send them to me so that I can evaluate them and (together with Warner in this case (As my mentor)) I will try to get them in as correctly and quickly as possible :-) (keeping up with the high standards of FreeBSD ofcourse). I also opened the PR database a couple weeks ago looking for a solution to bugs I encountered. It's been quite long, some years, since I opened the PR page last time. It was surprising and also disappointing on the number of PRs left open for long time. How do I help that cleaning job? I am also interested fixing and concerned about this fact. Thanks, Hiro ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
