Re: RELENG_7: something is very wrong with UDP?
Quoting Robert Watson [EMAIL PROTECTED]: On Fri, 19 Sep 2008, Oleg V. Nauman wrote: (1) Start by deleting all but one nameserver entry in /etc/resolv.conf. Confirm that you can still reproduce the problem. Due to various reasons my laptop running local caching DNS server ( named ) without any forwarders assigned. My /etc/resolv.conf contains nameserver 127.0.0.1 This is simplifying in some senses, but complicating in others. In particular, the question it raises is whether the problem is in the DNS resolver or the nameserver. Seeing a tcpdump of lo0 for DNS traffic would be quite interesting, since we could look at timestamps and try to place the blame a bit more precisely. Could you also use procstat -k on the dig process to generate a kernel stack trace for it? Let's add to this list: when the problem happens, could you also procstat -k the name server process(es)? And procstat -kk output for logger process waiting: PIDTID COMM TDNAME KSTACK 1421 100095 logger -mi_switch+0x2c8 sleepq_switch+0xd9 sleepq_catch_signals+0x239 sleepq_wait_sig+0x14 _sleep+0x35f pipe_read+0x389 dofileread+0x96 kern_readv+0x58 read+0x4f syscall+0x2b3 Xint0x80_syscall+0x20 Interesting -- logger is blocked on reading from a pipe, likely standard input. So it sounds like something else is failing to complete in a timely manner -- perhaps due to DNS. Nothing strange with this because it was kernel stack for logger waiting on background fsck output ( bgfsck was never starting though ) This is approximately the date of my last UDP MFC. Could you try backing out just src/sys/netinet6/udp6_usrreq.c revision 1.81.2.7 and see if that helps? (specifically, restore the use of sosend_generic instead of sosend_dgram) If you can show that it's definitely a problem with the change to sosend_dgram for UDPv6 socket send, then it might suggest it's the same problem that it is related to the UDPv46 code there. In which case I will propose we back out that portion of the change in the 7-stable branch until it's known to be resolved -- I don't want other people tripping over this. Sorry for false alarm regarding UDP issues.. Have noticed that my clock is stop incrementing ( it explaining the zeroes in traceroute output also ). It gave me idea what is related to this issue so performed backout revision 1.243.2.4 of src/sys/dev/acpica/acpi.c and it fixes my issues.. Looks like it stops incrementing the timecounters on my laptop.. Ironically speaking I was this ACPI behavior change initiator ( I was reporting ACPI HPET stops working on my RELENG_7 at July 19 to [EMAIL PROTECTED]) so jhb@ implemented a patch and it was working for me those days. Something was changed during the next 2 months so this patch causing issues instead the success on my hardware. I will play a bit with kern.timecounter.choice at Monday and report it back to jhb@ then. Could you try compiling your kernel with WITNESS to see if we get any extended debugging information? Have added WITNESS ( and STACK required by procstat ) options but it is not producing any output ( so no LORs or something like this ) OK. Could you try adding INVARIANT_SUPPORT and INVARIANTS if they aren't there? Be aware: this may convert the wedging you are experiencing into a kernel panic. No output produced with INVARIANT_SUPPORT and INVARIANTS support included in the kernel. And no kernel panic produced :) Thank you for excellent work. Is anybody experiencing the same issues with fresh RELENG_7? Unsure it is my local issues though I'm not experiencing them, but these sorts of things can be quite subtle and workload-dependent. Well experiencing this issue during the system boot even.. OK. So there must be something a bit different about your setup -- perhaps there's something specific about the way things are interacting over the loopback address for the name server. Is this the stock system BIND9 or something else? Are you able to temporarily switch to I have stock system BIND running an external name server and see if that changes things? Robert N M Watson Computer Laboratory University of Cambridge ___ 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: something is very wrong with UDP?
On Sat, 20 Sep 2008, Oleg V. Nauman wrote: Sorry for false alarm regarding UDP issues.. Have noticed that my clock is stop incrementing ( it explaining the zeroes in traceroute output also ). It gave me idea what is related to this issue so performed backout revision 1.243.2.4 of src/sys/dev/acpica/acpi.c and it fixes my issues.. Looks like it stops incrementing the timecounters on my laptop.. Ironically speaking I was this ACPI behavior change initiator ( I was reporting ACPI HPET stops working on my RELENG_7 at July 19 to [EMAIL PROTECTED]) so jhb@ implemented a patch and it was working for me those days. Something was changed during the next 2 months so this patch causing issues instead the success on my hardware. I will play a bit with kern.timecounter.choice at Monday and report it back to jhb@ then. OK, sounds like this is outside of my area of expertise, and indeed, John Baldwin is the right person to talk to. I've added him to the CC line so he can find the thread. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming Releases Schedule...
On Fri, 19 Sep 2008, Jo Rhett wrote: Look, I understand what you're saying here. And I don't discredit or disagree that it shouldn't be handled this way. But what you have addressed is a stepwise integration policy of a developer, and does not address how to get a business to commit those resources. Why? Because you are asking for the business to commit the resources without a goal. No, I'm not saying that FreeBSD has to guarantee anything. We both know that guarantees on open source projects aren't worth much. This whole discussion is about open source guarantees -- after some extensive discussions and careful thinking about available resources, the FreeBSD Project declared a set of guarantees about what FreeBSD versions we would continue to support over time. We tried to be realistic about the level of staffing available, the nature of the vulnerabilities that would arise, and the degree to which conservative highly incremental changes could be used to support a branch long after release. The problem is that the 18 months for all releases + extra time for extended support releases is still a short period of time. The tension here is between making promises we can definitely keep and starting to make promises that we can't. We'd like to err on the former, rather than latter, side. What I'm saying is that your scoped outline has no goal. Nothing to even reach for. Except maybe perhaps a commit bit for me. If I had wanted a commit bit, I'm sure I would have one by now. I'm not particularly worried about that. I don't even really care to have one (though I would if that was necessary). But that's the highest goal of your outlined scope. A commit bit. You already identified the end goal: extend support lifetimes. You placed constraint on how that could be accomplished: you were going to do the work. What I've done is identified our normal model for getting from the current starting point (a guy on a mailing list who, while enthusiastic, hasn't shown us the beef) to the proposed outcome (a guy on the security-officer team, commit access required to participate in the support process, etc). Here are the subgoals I broke it out into: - To really contribute to the discussion about support lifetimes and contribute during non-disclosure periods, you need to be on the security officer team and a FreeBSD committer. The former to you have access to the required information and discussion, the latter so that you can act on it. - To be on the security officer team, you need to be a FreeBSD committer in good standing who has shown both the technical acumen and long-term commitment to the project required to work effectively on that team. Because sensitive information is involved, and because we give the security officer team special privileges in the project to accomplish its task, we select proposed members very carefully. - To be a FreeBSD committer, you need to have show a signficant long-term commitment to the project, the ability to identify and work with a mentor, and build the confidence of the core team that you are a candidate in whom we can place significant trust (direct write access to the source code of a system deploy on literally millions of devices). - To show a significant long-term commitment to the project, you need to identify past work and context for your potential future contributions and find a potential mentor (committer) with whom you have an existing professional relationship. Common examples are things like has worked with you over an extended period to get your work merged, or someone who has been watching your work over time and concluded that they are in a good position to go through the mentoring process with you. If you've seen the appropriate Southpark episode: Step 3: Profit! Dude, what's step 2? Let's make sure we understand each other clearly: the reason you're getting replies using words like demand is that it is easy to read your e-mails in exactly the above light. It is not a stretch to interpret them as reading, Put me on the security officer team without having gone through any of the normal processes used to vet a new member. We can talk about changing the process, but I think you can't contribute to that conversation constructively without understanding the process. Simply demanding change (and that's how it reads) shows a lack of respect for how we got to where we are, and puts people people on the defensive. Or offensive, in some cases. :-) There's *nothing* wrong with what you have said. What you have said makes perfect sense from an integration perspective. But I don't think it addresses the issues at hand -- businesses need to have explicit goals and at least a haphazard guess at the requirements to reach those goals before they'll commit resources. If you approach a software company and say Look, we like your product, but it would really help us if
Re: RELENG_7 hangs on boot w/Gigabyte MA78GM-S2H MB
On Fri, Sep 19, 2008 at 11:24:18PM -0500, Bob Willcox wrote: Hi All, I'm trying to get the latest RELENG_7 to run on my new Gigabyte MA78GM-S2H motherboard and am experiencing a hang on boot right after it prints the message: Trying to mount root from ufs:/dev/ad4s1a At this point it is hung and doesn't respond to any keyboard input. I originally attempted to install the 7.1 beta system with similar results (prevented me from installing). I then installed 7.0-release and though the install succeeded it never did see the Realtek ethernet controller so I had no network capability. You're describing multiple problems in a single Email. This is liable to get complex. 1) It would be helpful to know if you installed i386 or amd64 FreeBSD, 2) With regards to the lock-up after mount root, if you press NumLock or CapsLock, do the keyboard LEDs turn on/off? 3) Many others have seen the hanging/lock-up after mount root. I believe one found a workaround by setting ATA_STATIC_ID in their kernel configuration. I realise this is a problem when you can't get the system up to a point of building a kernel; chicken-and-egg problem, 4) The Realtek NIC on that motherboard is probably too new to be supported under RELENG_7. Realtek has a history of releasing different sub-revisions of the same NIC/PHY, and the internal changes are severe enough to cause the NIC to not work correctly (under any OS) without full driver support for that specific sub-revision. All above said: Can you please try one of the RELENG_7 ISO snapshots at the below site, instead of the official 7.0-RELEASE ISO, and report back if that solves either of your problems? The below site contains ISOs built daily, rather than monthly: http://pub.allbsd.org/FreeBSD-snapshots/ -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ 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 hangs on boot w/Gigabyte MA78GM-S2H MB
On Sat, Sep 20, 2008 at 05:39:14AM -0700, Jeremy Chadwick wrote: On Fri, Sep 19, 2008 at 11:24:18PM -0500, Bob Willcox wrote: Hi All, I'm trying to get the latest RELENG_7 to run on my new Gigabyte MA78GM-S2H motherboard and am experiencing a hang on boot right after it prints the message: Trying to mount root from ufs:/dev/ad4s1a At this point it is hung and doesn't respond to any keyboard input. I originally attempted to install the 7.1 beta system with similar results (prevented me from installing). I then installed 7.0-release and though the install succeeded it never did see the Realtek ethernet controller so I had no network capability. You're describing multiple problems in a single Email. This is liable to get complex. Sorry, that wasn't my intention. I was just trying to document my experience with this particular motherboard (I have a number of others that work fine with FreeBSD 7-stable, this one I'm typing this on is a very similar Gigabyte board in fact). 1) It would be helpful to know if you installed i386 or amd64 FreeBSD, This is amd64 on this particular machine. 2) With regards to the lock-up after mount root, if you press NumLock or CapsLock, do the keyboard LEDs turn on/off? Nope, no keys do anything. You must either push reset or pull the plug. 3) Many others have seen the hanging/lock-up after mount root. I believe one found a workaround by setting ATA_STATIC_ID in their kernel configuration. I realise this is a problem when you can't get the system up to a point of building a kernel; chicken-and-egg problem, Well, I can build a kernel if I run the 7.0-release kernel. That's how I got to 7-stable on the machine in the first place. I used sneaker net to copy it to this one via a CD (as I mentioned, the 7.0 kernel boots but the Realtek ethernet device is not recognized). 4) The Realtek NIC on that motherboard is probably too new to be supported under RELENG_7. Realtek has a history of releasing different sub-revisions of the same NIC/PHY, and the internal changes are severe enough to cause the NIC to not work correctly (under any OS) without full driver support for that specific sub-revision. That's what I suspected. The values displayed when doing a pciconf -lv are similar as for this system I'm using to type this, but now that I look closer and make a direct comparison, the failing device has a rev=0x02 vs. rev=0x01 for the working one. The pciconf -lv output for the failing mb is: [EMAIL PROTECTED]:2:0:0: class=0x02 card=0xe0001458 chip=0x816810ec rev=0x02 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC' class = network subclass = ethernet All above said: Can you please try one of the RELENG_7 ISO snapshots at the below site, instead of the official 7.0-RELEASE ISO, and report back if that solves either of your problems? The below site contains ISOs built daily, rather than monthly: I'll be happy to try that, but the kernel I most recently tried was from 7-stable source that I cvsup'd just yesterday. Since both the official 7.1-BETA and very recent 7-stable hang the same way I suspect that all of the newer kernels will experience this hang. Let me know if you still think it's worth trying one of the snapshots. I do plan to try the ATA_STATIC_ID setting that you mentioned above to see if that helps. Let me know if there is anything else I should try. I am able to build kernels so long as I run the 7.0 kernel (and work around the network problem). Thanks for your time response! Bob http://pub.allbsd.org/FreeBSD-snapshots/ -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | -- Bob Willcox All the evidence concerning the universe [EMAIL PROTECTED] has not yet been collected, so there's still hope. Austin, TX ___ 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 hangs on boot w/Gigabyte MA78GM-S2H MB
On Sat, Sep 20, 2008 at 08:24:29AM -0500, Bob Willcox wrote: 1) It would be helpful to know if you installed i386 or amd64 FreeBSD, This is amd64 on this particular machine. 2) With regards to the lock-up after mount root, if you press NumLock or CapsLock, do the keyboard LEDs turn on/off? Nope, no keys do anything. You must either push reset or pull the plug. Is it possible to get the output when booting in verbose mode? If not, what are the last few lines before the machine locks up when booting verbosely? 3) Many others have seen the hanging/lock-up after mount root. I believe one found a workaround by setting ATA_STATIC_ID in their kernel configuration. I realise this is a problem when you can't get the system up to a point of building a kernel; chicken-and-egg problem, Well, I can build a kernel if I run the 7.0-release kernel. That's how I got to 7-stable on the machine in the first place. I used sneaker net to copy it to this one via a CD (as I mentioned, the 7.0 kernel boots but the Realtek ethernet device is not recognized). So the problem is that 7.0-RELEASE works fine for you, but after upgrading your RELENG_7 source (to what is now 7.1-BETA), the machine hangs after printing the mount root message. Is this correct? Here's another question: does booting into single-user exhibit the same problem as multi-user? 4) The Realtek NIC on that motherboard is probably too new to be supported under RELENG_7. Realtek has a history of releasing different sub-revisions of the same NIC/PHY, and the internal changes are severe enough to cause the NIC to not work correctly (under any OS) without full driver support for that specific sub-revision. That's what I suspected. The values displayed when doing a pciconf -lv are similar as for this system I'm using to type this, but now that I look closer and make a direct comparison, the failing device has a rev=0x02 vs. rev=0x01 for the working one. The pciconf -lv output for the failing mb is: [EMAIL PROTECTED]:2:0:0: class=0x02 card=0xe0001458 chip=0x816810ec rev=0x02 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC' class = network subclass = ethernet Regarding the Realtek issue: I've CC'd PYUN Yong-Hyeon (surname in caps), who maintains the re(4) driver for FreeBSD. He might have a patch available for you to try, or help determine how to get this NIC working on FreeBSD. He'll probably need more than just pciconf -lv output, but should be able to work with you. Thanks! -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Problem with dtrace
Still testing FreeBSD-7.1-beta encountered the following (perhaps to be expected) result with dtrace: dtrace -m kernel - some output - deadlock after a few seconds. Less demanding tracing worked OK. -- Michel TALON ___ 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 hangs on boot w/Gigabyte MA78GM-S2H MB
On Sat, Sep 20, 2008 at 07:04:56AM -0700, Jeremy Chadwick wrote: On Sat, Sep 20, 2008 at 08:24:29AM -0500, Bob Willcox wrote: 1) It would be helpful to know if you installed i386 or amd64 FreeBSD, This is amd64 on this particular machine. 2) With regards to the lock-up after mount root, if you press NumLock or CapsLock, do the keyboard LEDs turn on/off? Nope, no keys do anything. You must either push reset or pull the plug. Is it possible to get the output when booting in verbose mode? If not, what are the last few lines before the machine locks up when booting verbosely? Yep, just did that. The last things printed right before hang are: ioapic0: Assigning ISA IRQ 1 to local APIC 0 ioapic0: Assigning ISA IRQ 4 to local APIC 1 ioapic0: Assigning ISA IRQ 6 to local APIC 2 ioapic0: Assigning ISA IRQ 7 to local APIC 0 ioapic0: Assigning ISA IRQ 9 to local APIC 1 ioapic0: Assigning ISA IRQ 12 to local APIC 2 ioapic0: Assigning ISA IRQ 14 to local APIC 0 ioapic0: Assigning ISA PCI 16 to local APIC 1 ioapic0: Assigning ISA PCI 17 to local APIC 2 ioapic0: Assigning ISA PCI 18 to local APIC 0 ioapic0: Assigning ISA PCI 19 to local APIC 1 ioapic0: Assigning ISA PCI 22 to local APIC 2 trying to mount root from ufs:/dev/ad4s1a start_init: trying /sbin/init [hung at this point] 3) Many others have seen the hanging/lock-up after mount root. I believe one found a workaround by setting ATA_STATIC_ID in their kernel configuration. I realise this is a problem when you can't get the system up to a point of building a kernel; chicken-and-egg problem, Well, I can build a kernel if I run the 7.0-release kernel. That's how I got to 7-stable on the machine in the first place. I used sneaker net to copy it to this one via a CD (as I mentioned, the 7.0 kernel boots but the Realtek ethernet device is not recognized). So the problem is that 7.0-RELEASE works fine for you, but after upgrading your RELENG_7 source (to what is now 7.1-BETA), the machine hangs after printing the mount root message. Is this correct? Yes, that is pretty much it. The Realtek ethernet isn't working in in 7.0-RELEASE either, but I'm guessing that that is a different (and less serious) problem related to changes in that device. Here's another question: does booting into single-user exhibit the same problem as multi-user? It looks like when I try a single-user mode (and verbose) boot the only difference is that the las line shown above (the start_init line) isn't printed. Otherwise, the hang is the same. 4) The Realtek NIC on that motherboard is probably too new to be supported under RELENG_7. Realtek has a history of releasing different sub-revisions of the same NIC/PHY, and the internal changes are severe enough to cause the NIC to not work correctly (under any OS) without full driver support for that specific sub-revision. That's what I suspected. The values displayed when doing a pciconf -lv are similar as for this system I'm using to type this, but now that I look closer and make a direct comparison, the failing device has a rev=0x02 vs. rev=0x01 for the working one. The pciconf -lv output for the failing mb is: [EMAIL PROTECTED]:2:0:0: class=0x02 card=0xe0001458 chip=0x816810ec rev=0x02 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC' class = network subclass = ethernet Regarding the Realtek issue: I've CC'd PYUN Yong-Hyeon (surname in caps), who maintains the re(4) driver for FreeBSD. He might have a patch available for you to try, or help determine how to get this NIC working on FreeBSD. He'll probably need more than just pciconf -lv output, but should be able to work with you. Ok, that'd be great. I must say that I'm close to simply returning this MB and going with something not quite so new that is more likely to work. I was hoping to get this system up and running this weekend. :( Thanks, Bob Thanks! -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | -- Bob Willcox All the evidence concerning the universe [EMAIL PROTECTED] has not yet been collected, so there's still hope. Austin, TX ___ 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 hangs on boot w/Gigabyte MA78GM-S2H MB
On Sat, Sep 20, 2008 at 09:45:10AM -0500, Bob Willcox wrote: On Sat, Sep 20, 2008 at 07:04:56AM -0700, Jeremy Chadwick wrote: On Sat, Sep 20, 2008 at 08:24:29AM -0500, Bob Willcox wrote: 1) It would be helpful to know if you installed i386 or amd64 FreeBSD, This is amd64 on this particular machine. 2) With regards to the lock-up after mount root, if you press NumLock or CapsLock, do the keyboard LEDs turn on/off? Nope, no keys do anything. You must either push reset or pull the plug. Is it possible to get the output when booting in verbose mode? If not, what are the last few lines before the machine locks up when booting verbosely? Yep, just did that. The last things printed right before hang are: ioapic0: Assigning ISA IRQ 1 to local APIC 0 ioapic0: Assigning ISA IRQ 4 to local APIC 1 ioapic0: Assigning ISA IRQ 6 to local APIC 2 ioapic0: Assigning ISA IRQ 7 to local APIC 0 ioapic0: Assigning ISA IRQ 9 to local APIC 1 ioapic0: Assigning ISA IRQ 12 to local APIC 2 ioapic0: Assigning ISA IRQ 14 to local APIC 0 ioapic0: Assigning ISA PCI 16 to local APIC 1 ioapic0: Assigning ISA PCI 17 to local APIC 2 ioapic0: Assigning ISA PCI 18 to local APIC 0 ioapic0: Assigning ISA PCI 19 to local APIC 1 ioapic0: Assigning ISA PCI 22 to local APIC 2 trying to mount root from ufs:/dev/ad4s1a start_init: trying /sbin/init [hung at this point] 3) Many others have seen the hanging/lock-up after mount root. I believe one found a workaround by setting ATA_STATIC_ID in their kernel configuration. I realise this is a problem when you can't get the system up to a point of building a kernel; chicken-and-egg problem, Well, I can build a kernel if I run the 7.0-release kernel. That's how I got to 7-stable on the machine in the first place. I used sneaker net to copy it to this one via a CD (as I mentioned, the 7.0 kernel boots but the Realtek ethernet device is not recognized). So the problem is that 7.0-RELEASE works fine for you, but after upgrading your RELENG_7 source (to what is now 7.1-BETA), the machine hangs after printing the mount root message. Is this correct? Yes, that is pretty much it. The Realtek ethernet isn't working in in 7.0-RELEASE either, but I'm guessing that that is a different (and less serious) problem related to changes in that device. Here's another question: does booting into single-user exhibit the same problem as multi-user? It looks like when I try a single-user mode (and verbose) boot the only difference is that the las line shown above (the start_init line) isn't printed. Otherwise, the hang is the same. 4) The Realtek NIC on that motherboard is probably too new to be supported under RELENG_7. Realtek has a history of releasing different sub-revisions of the same NIC/PHY, and the internal changes are severe enough to cause the NIC to not work correctly (under any OS) without full driver support for that specific sub-revision. That's what I suspected. The values displayed when doing a pciconf -lv are similar as for this system I'm using to type this, but now that I look closer and make a direct comparison, the failing device has a rev=0x02 vs. rev=0x01 for the working one. The pciconf -lv output for the failing mb is: [EMAIL PROTECTED]:2:0:0: class=0x02 card=0xe0001458 chip=0x816810ec rev=0x02 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC' class = network subclass = ethernet Regarding the Realtek issue: I've CC'd PYUN Yong-Hyeon (surname in caps), who maintains the re(4) driver for FreeBSD. He might have a patch available for you to try, or help determine how to get this NIC working on FreeBSD. He'll probably need more than just pciconf -lv output, but should be able to work with you. Ok, that'd be great. I must say that I'm close to simply returning this MB and going with something not quite so new that is more likely to work. I was hoping to get this system up and running this weekend. :( I wish I knew what was causing the lock-up for you. I'm truly baffled, especially given that the system is able to boot + find the kernel + load kernel modules. Debugging this problem is out of field; jhb@ might have some ideas, as I'm not sure what magic happens immediately before the root filesystem is mounted. Those debugging/helping may want disklabel -r -A ad4s1 output. At least you can boot 7.0-RELEASE to get that information. Regarding hardware: I myself purchased an Asus P5Q SE board, with an Intel Q9550 CPU earlier this week. The board was affordable (barely US$100). One of the reasons I went with this board is because it lacks a) Realtek NICs, b) Broadcom NICs, c) JMicron SATA controllers, and d) Silicon Image SATA controllers. All of those are devices I stay away from. The Atheros/Attansic L1E NIC is known
Re: Supermicro PDSMI failed to boot on fresh RELENG_7/amd64
On Wed, 17 Sep 2008, Jeremy Chadwick wrote:
JC 3 of 4 times this machine failed to boot, panicing somewhere in late
kernel
JC initialization phase (before /sbin/init is executed)
JC
JC {snip}
JC
JC We have many (specifically, 6) PDSMI+ (not PDSMI) boxes which do not
JC exhibit this problem.
Next followup: RELENG_7/i386 is working well, only amd64 exhibits problems.
Sincerely,
D.Marck [DM5020, MCK-RIPE, DM3-RIPN]
[ FreeBSD committer: [EMAIL PROTECTED] ]
*** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [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: Supermicro PDSMI failed to boot on fresh RELENG_7/amd64
Dmitry Morozovsky wrote:
On Wed, 17 Sep 2008, Jeremy Chadwick wrote:
JC 3 of 4 times this machine failed to boot, panicing somewhere in late kernel
JC initialization phase (before /sbin/init is executed)
JC
JC {snip}
JC
JC We have many (specifically, 6) PDSMI+ (not PDSMI) boxes which do not
JC exhibit this problem.
Next followup: RELENG_7/i386 is working well, only amd64 exhibits problems.
I am not sure if this was fixed since last week but i386 also showed the
same issues on -current
Sincerely,
D.Marck [DM5020, MCK-RIPE, DM3-RIPN]
[ FreeBSD committer: [EMAIL PROTECTED] ]
*** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] ***
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [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: RELENG_7 hangs on boot w/Gigabyte MA78GM-S2H MB
On Sat, Sep 20, 2008 at 08:05:33AM -0700, Jeremy Chadwick wrote: On Sat, Sep 20, 2008 at 09:45:10AM -0500, Bob Willcox wrote: On Sat, Sep 20, 2008 at 07:04:56AM -0700, Jeremy Chadwick wrote: On Sat, Sep 20, 2008 at 08:24:29AM -0500, Bob Willcox wrote: 1) It would be helpful to know if you installed i386 or amd64 FreeBSD, This is amd64 on this particular machine. 2) With regards to the lock-up after mount root, if you press NumLock or CapsLock, do the keyboard LEDs turn on/off? Nope, no keys do anything. You must either push reset or pull the plug. Is it possible to get the output when booting in verbose mode? If not, what are the last few lines before the machine locks up when booting verbosely? Yep, just did that. The last things printed right before hang are: ioapic0: Assigning ISA IRQ 1 to local APIC 0 ioapic0: Assigning ISA IRQ 4 to local APIC 1 ioapic0: Assigning ISA IRQ 6 to local APIC 2 ioapic0: Assigning ISA IRQ 7 to local APIC 0 ioapic0: Assigning ISA IRQ 9 to local APIC 1 ioapic0: Assigning ISA IRQ 12 to local APIC 2 ioapic0: Assigning ISA IRQ 14 to local APIC 0 ioapic0: Assigning ISA PCI 16 to local APIC 1 ioapic0: Assigning ISA PCI 17 to local APIC 2 ioapic0: Assigning ISA PCI 18 to local APIC 0 ioapic0: Assigning ISA PCI 19 to local APIC 1 ioapic0: Assigning ISA PCI 22 to local APIC 2 trying to mount root from ufs:/dev/ad4s1a start_init: trying /sbin/init [hung at this point] 3) Many others have seen the hanging/lock-up after mount root. I believe one found a workaround by setting ATA_STATIC_ID in their kernel configuration. I realise this is a problem when you can't get the system up to a point of building a kernel; chicken-and-egg problem, Well, I can build a kernel if I run the 7.0-release kernel. That's how I got to 7-stable on the machine in the first place. I used sneaker net to copy it to this one via a CD (as I mentioned, the 7.0 kernel boots but the Realtek ethernet device is not recognized). So the problem is that 7.0-RELEASE works fine for you, but after upgrading your RELENG_7 source (to what is now 7.1-BETA), the machine hangs after printing the mount root message. Is this correct? Yes, that is pretty much it. The Realtek ethernet isn't working in in 7.0-RELEASE either, but I'm guessing that that is a different (and less serious) problem related to changes in that device. Here's another question: does booting into single-user exhibit the same problem as multi-user? It looks like when I try a single-user mode (and verbose) boot the only difference is that the las line shown above (the start_init line) isn't printed. Otherwise, the hang is the same. 4) The Realtek NIC on that motherboard is probably too new to be supported under RELENG_7. Realtek has a history of releasing different sub-revisions of the same NIC/PHY, and the internal changes are severe enough to cause the NIC to not work correctly (under any OS) without full driver support for that specific sub-revision. That's what I suspected. The values displayed when doing a pciconf -lv are similar as for this system I'm using to type this, but now that I look closer and make a direct comparison, the failing device has a rev=0x02 vs. rev=0x01 for the working one. The pciconf -lv output for the failing mb is: [EMAIL PROTECTED]:2:0:0: class=0x02 card=0xe0001458 chip=0x816810ec rev=0x02 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC' class = network subclass = ethernet Regarding the Realtek issue: I've CC'd PYUN Yong-Hyeon (surname in caps), who maintains the re(4) driver for FreeBSD. He might have a patch available for you to try, or help determine how to get this NIC working on FreeBSD. He'll probably need more than just pciconf -lv output, but should be able to work with you. Ok, that'd be great. I must say that I'm close to simply returning this MB and going with something not quite so new that is more likely to work. I was hoping to get this system up and running this weekend. :( I wish I knew what was causing the lock-up for you. I'm truly baffled, especially given that the system is able to boot + find the kernel + load kernel modules. Debugging this problem is out of field; jhb@ might have some ideas, as I'm not sure what magic happens immediately before the root filesystem is mounted. Those debugging/helping may want disklabel -r -A ad4s1 output. At least you can boot 7.0-RELEASE to get that information. Regarding hardware: I myself purchased an Asus P5Q SE board, with an Intel Q9550 CPU earlier this week. The board was affordable (barely US$100). One of the reasons I went with this board is because it lacks a)
Re: RELENG_7 hangs on boot w/Gigabyte MA78GM-S2H MB
On Sat, 20 Sep 2008, Jeremy Chadwick wrote: [snip all] JC I myself purchased an Asus P5Q SE board, with an Intel Q9550 CPU earlier JC this week. The board was affordable (barely US$100). One of the JC reasons I went with this board is because it lacks a) Realtek NICs, b) JC Broadcom NICs, c) JMicron SATA controllers, and d) Silicon Image SATA JC controllers. All of those are devices I stay away from. Hmm, side question: why do you hate bge(4)? We have a bunch of gigabit routers/natters with bge, and they perform reasonably well (mostly ASUS M2N-LR mobo)... Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: [EMAIL PROTECTED] ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [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: Upcoming Releases Schedule...
On Sat, Sep 20, 2008 at 11:37:25AM +0100, Robert Watson wrote: You already identified the end goal: extend support lifetimes. You placed constraint on how that could be accomplished: you were going to do the work. Actually Robert, to be fair to Jo, I suspect it is more proper to say $COMPANY wants extended support lifetimes. What can I, or $COMPANY, do to help make that happen?. I think its been misinterpreted as Jo saying Let me do the work. He has offered to see if his company will let him help on company time, but I do not believe the constraint is quite as you phrased it above. The goal is the same, but throw it open to a wider contraint set - what resources does the project need to make it happen? Money? Test labs? Server hosting? Twinkies? Rgeards, Gary ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
BPF plans for 7.1
Hi, Will the zero-copy bpf(4) changes be merged to the stable branch before the release? Thanks, Vlad -- ~/.signature: no such file or directory ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming Releases Schedule...
On 2008.09.19 21:30:11 -0700, Jo Rhett wrote: On Sep 19, 2008, at 8:57 PM, David N wrote: How long are you expecting support for a RELENG to last, 1, 2, 3 years? 5 years? (comparison, Ubuntu LTS is 3 years, security updates) 2 years for each supported branch would be excellent, although I'm open to alternatives. Right now 6.4 will EoL before 6.3 will :-( Eh, where did you get that information? AFAIK the EoL date of 6.4 has not yet been decided (and I should know though of course I could have missed it). The EoL date is normally decided right around the release time. In the past it was done post-release but lately it has been done before the release to include info in the release announcement. If, when we get closer to the actual release, still is the plan for 6.4 to be the last RELENG_6 release I'm almost certain 6.4 will be a Extended Support release. On 2008.09.19 22:43:56 -0700, Jo Rhett wrote: On Sep 19, 2008, at 9:41 PM, Gary Palmer wrote: On Fri, Sep 19, 2008 at 07:38:32PM -0700, Jo Rhett wrote: Without input from the current release team extending the support schedule is not possible. Inquiry - is release team the constraint? I don't know. I asked why not, and was told the release team said this was all they could do with the resources they have. No further information has been provided. Initially, the description is from my world view. It's entirely possible I miss some parts, have forgotten, or remember incorrectly. /disclaimer OK, before being able to say what is required for support, we need to define support. Currently the entities which has a defined support for releases is the FreeBSD Security Team (secteam) which supports the base system for RELENG_* as defined out the security website [1], and the FreeBSD Ports Management Team which has defined support for the FreeBSD Ports Collection. The security team will, for the defined periods, do it's utmost to make sure security issues identifies in the supported branches are fixed. When it has been published how long a release is supported, that period may at times be extended, but it's never shortened. It should be mentioned in this regard that after a release is out the door and hasn't blown up requiring a point release to fix it (think 4.6.2 / 5.2.1) the security team owns the release branch, so to speak. The Ports Collection has a slightly more vague definition of what is supported [2], but it is still documented. Ports normally support the releases secteam does, but they could support less if they want to. For the Ports Collection there is also two parts to that support (and that's the reason I write support with quotes). One part is the ports infrastructure (bsd.ports.mk and more) which portmgr and others do a lot to make sure works on the supported releasess. The other part is the ~19000 individual ports. The individual ports, to a degree, supports what the maintainer of that port has an interest in supporting. While there are of course rules and guidelines for what a port must support, if a maintainer doesn't want to spend time supporting it there aren't that much anyone else can do about it (if somebody else cares enough they can submit patches, but e.g. for X000 broken ports that's a lot of work). The Release Engineering team implicitly (as in that I don't think they ever defined this per policy but it's what effectively being done) support whatever secteam supports, wrt. for Errata Notices. As the security team own the release branches (RELENG_X_Y) secteam is also involved at least partly in each Errata Notice which goes out. Now, to define what the above support requires. For the ports collection (if we ignore the part with individual ports maintainers) requires quite a lot of time per release to support (especially for older releases), as all infrastructure changes has to be tested on all supported versions, and for each supported release and architecture there need to be hardware to build packages. I'm not going to go more into this as I'm not involved with this so I don't know the details on than that it's non-trivial both wrt. time and hardware. For what secteam support of the base system costs, it's mainly time for the members of the security team which is the cost. The more branches, the more time is required. This is not a linear cost and has multiple parts to it: - The more branches are supported, the more likely it is we need to deal with a security issue for third party software. Both because software is added/removed in newer branches so we might only support a given program in old branches (e.g. GNU tar, GNU gzip, GNU cpio and more hare not in newer FreeBSD versions). It's also possible that an older release will have a vulnerable version, but newer FreeBSD versions are not vulnerable due to newer version of the third party software. It also happens that an FreeBSD specific issue has silently / unknowingly to the security impact been fixed in
Re: Supermicro PDSMI failed to boot on fresh RELENG_7/amd64
On Sat, Sep 20, 2008 at 08:11:51PM +0400, Dmitry Morozovsky wrote:
On Wed, 17 Sep 2008, Jeremy Chadwick wrote:
JC 3 of 4 times this machine failed to boot, panicing somewhere in late
kernel
JC initialization phase (before /sbin/init is executed)
JC
JC {snip}
JC
JC We have many (specifically, 6) PDSMI+ (not PDSMI) boxes which do not
JC exhibit this problem.
Next followup: RELENG_7/i386 is working well, only amd64 exhibits problems.
Interesting. There's another recent post about this problem, also using
amd64.
http://lists.freebsd.org/pipermail/freebsd-stable/2008-September/045170.html
--
| Jeremy Chadwickjdc at parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP: 4BD6C0CB |
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problem with dtrace
In the last episode (Sep 20), Michel Talon said: Still testing FreeBSD-7.1-beta encountered the following (perhaps to be expected) result with dtrace: dtrace -m kernel - some output - deadlock after a few seconds. Less demanding tracing worked OK. proc, profile, and syscall probes work fine for me; it seems to be just fbt probes that cause problems. Enabling any one will cause a trap 12 a few instructions inside the probed function when it gets called. -- Dan Nelson [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Freebsd custom installation cd
Hello, I created custom freebsd installation cd with custom kernel. When I boot system with custom cd; kernel detects Intel ICH9 sata300 controller but end of the bootingit doesnt detect my sata disk. Mainboard is intel and chipset is i965. There is no problem when I use this custom cd with gigabyte p35 chipset mainboard with same sata disk When I use the freebsd live cd it detects atapci0 Marvell 88SX6101 and atapci1 Intel Ahci Controller then it detects disk without problem. My kernel conf file is below. Where can be the problem? Thanks. cpu I486_CPUcpu I586_CPUcpu I686_CPUident FREEBSD-CDBOOT# To statically compile in device wiring instead of /boot/device.hints#hints GENERIC.hints # Default places to look for devices.#makeoptionsDEBUG=-g# Build kernel with gdb(1) debug symbolsoptions SCHED_4BSD # 4BSD scheduleroptions PREEMPTION # Enable kernel thread preemptionoptions INET# InterNETworking#options INET6 # IPv6 communications protocols#optionsSCTP # Stream Control Transmission Protocoloptions FFS # Berkeley Fast Filesystemoptions SOFTUPDATES # Enable FFS soft updates supportoptions UFS_ACL # Support for access control listsoptions UFS_DIRHASH # Improve performance on big directories#optionsUFS_GJOURNAL # Enable gjournal-based UFS journalingoptions MD_ROOT # MD is a potential root deviceoptions MD_ROOT_SIZE=3options NFSCLIENT # Network Filesystem Client#options NFSSERVER # Network Filesystem Serveroptions NFS_ROOT # NFS usable as /, requires NFSCLIENToptions MSDOSFS # MSDOS Filesystemoptions CD9660 # ISO 9660 Filesystemoptions PROCFS # Process filesystem (requires PSEUDOFS)options PSEUDOFS# Pseudo-filesystem frameworkoptions GEOM_PART_GPT # GUID Partition Tables.options GEOM_LABEL # Provides labelizationoptions COMPAT_43TTY# BSD 4.3 TTY compat [KEEP THIS!]options COMPAT_FREEBSD4 # Compatible with FreeBSD4options COMPAT_FREEBSD5 # Compatible with FreeBSD5options COMPAT_FREE BSD6 # Compatible with FreeBSD6options SCSI_DELAY=5000 # Delay (in ms) before probing SCSIoptions KTRACE # ktrace(1) supportoptions SYSVSHM # SYSV-style shared memoryoptions SYSVMSG # SYSV-style message queuesoptions SYSVSEM # SYSV-style semaphoresoptions _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensionsoptions KBD_INSTALL_CDEV# install a CDEV entry in /devoptions ADAPTIVE_GIANT # Giant mutex is adaptive.options STOP_NMI # Stop CPUS using NMI instead of IPI#optionsAUDIT # Security event auditing#options QUOTA#options IPFIREWALL#options IPFIREWALL_VERBOSE#options IPFIREWALL_VERBOSE_LIMIT=5#options IPFIREWALL_FORWARD#options IPFIREWALL_NAT#options IPDIVERT#options DUMMYNET#options IP STEALTH#options NETGRAPHoptions NETGRAPH_BPFoptions NETGRAPH_BRIDGEoptions NETGRAPH_DEVICEoptions NETGRAPH_ECHOoptions NETGRAPH_ETHERoptions NETGRAPH_GIFoptions NETGRAPH_GIF_DEMUXoptions NETGRAPH_HOLEoptions NETGRAPH_TAGoptions NETGRAPH_IFACEoptions NETGRAPH_IP_INPUToptions NETGRAPH_IPFWoptions NETGRAPH_KSOCKEToptions NETGRAPH_NAT#options IPFIREWALL_DEFAULT_TO_ACCEPT#options LIBALIASoptions NETGRAPH_NETFLOWoptions NETGRAPH_PPPoptions NETGRAPH_SOCKEToptions NETGRAPH_SPLIToptions NETGRAPH_TCPMSSoptions NETGRAPH_TEEoptions NETGRAPH_TTYoptions NETGRAPH_UI#options HZ=1000#options IPSEC#options IPSEC_FILTERTUNNEL#device crypto# To make an SMP kernel, the next two lines are needed#optionsSMP # Symmetric MultiProcessor Kerneldevice apic# I/O APIC# CPU frequency control#device cpufreq# Bus support.device eisadevice pci# Floppy drivesdevice fdc# ATA and ATAPI devicesdevice atadevice atadisk # ATA disk drivesdevice ataraid # ATA RAID drivesdevice atapicd # ATAPI CDROM drives#device atapifd # ATAPI floppy
Re: Freebsd custom installation cd
On Sun, Sep 21, 2008 at 01:20:51AM +0300, yusuf özbilgin wrote: Hello, I created custom freebsd installation cd with custom kernel. When I boot system with custom cd; kernel detects Intel ICH9 sata300 controller but end of the bootingit doesnt detect my sata disk. When you say it doesn't detect my SATA disk, what do you mean? Does the system lock up after saying Mounting root from...? Please let me know -- it's very important. Mainboard is intel and chipset is i965. There is no problem when I use this custom cd with gigabyte p35 chipset mainboard with same sata disk When I use the freebsd live cd it detects atapci0 Marvell 88SX6101 and atapci1 Intel Ahci Controller then it detects disk without problem. My kernel conf file is below. No one can read your kernel configuration because what you posted lacks newlines. Additionally, you said you're using a custom FreeBSD installation CD, which may be part of the problem as well (since you admit the Live CD works fine). -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GELI encrypted ZFS zpool
Steve Bertrand [EMAIL PROTECTED] wrote: I have an older storage box that I've upgraded to -stable. It currently uses 7 SCSI disks mashed together with gstripe. I've recently replaced this box with a new one running a ZFS setup. I'm now wanting to turn the old one into a storage device running ZFS, but I want the entire pool encrypted with GELI. I know I can do this, but my requirements are as such: - use a key on external media to access the GELI encrypted disks - not have to type in the passphrase for each physical disk ...is this possible? It should be possible if you use keyfiles without password for the vdevs and store those keyfiles on a geli encrypted slice that uses both a keyfile and a passphrase. Fabian signature.asc Description: PGP signature
Re: Upcoming Releases Schedule...
Robert Watson wrote: When it comes to commercial OS products, like Windows and Mac OS X, there is often a strict requirement to live on the most recent minor release in order to continue to receive support. For example, you won't make a lot of headway turning up at Apple and demanding security updates for Mac OS X 10.5.0 a year after it has been released. The answer will be Great, update 10.5.3 (or something along those lines) -- not only will it fix the security issues, but it will support the hardware we now sell. In that sense, we're actually quite different: rather than saying Sorry, 6.2 is vulnerable, please upgrade to 6.3, we say You can live on 6.2 for up to 18 months and receive *only* security and critical errata patches. Don't get me wrong: I would love to see us support all releases for 24 months (or even more) after they ship. I think our users would appreciate that also. Perhaps there is a middle ground here? What about a statement that each major branch (6.x, 7.x) will be supported for at least 24+ months from its last production release? Smaller periods of support could be given to minor releases along the way (7.2, for example), but at least companies would know that if they installed a 6.x version, they'd have support for a couple of years, even if that might mean upgrading to a newer minor version if there was a problem. I really wouldn't mind being told to upgrade from 7.2 to 7.4_p12 because its been 20 months since the last 7.x release. Because companies are used to the Apple and Microsoft way you outlined above, I don't think they'd have a huge problem with it either. Wouldn't it make it easier on the teams to only ofter extended support for the major versions, rather than trying to support specific minor versions (6.3, 6.4, 7.0, 7.1) for an extended time? I'll admit, in the early days of 5.x, I really didn't like having to jump between minor versions. Let's face it, things didn't really settle down until, what, 5.3? In those days, being able to stay on a specific minor release was a Good Thing. However, I don't have the same kind of API and upgrade fear going from 6.x to 6.y. Maybe there are people out there who truly fear upgrading from 6.3 to 6.4, and need both supported for an extended time. But if resources are limited, it seems that only offering extended support for the latest release from a major branch would be the way to go. Perhaps 6-12 months for a minor release, 24+ months for the entire major release train? I'm not demanding anything, or saying this is the right way. I'm just wondering if there is a compromise out there that would give companies the security that their 6.x or 7.x server will have 2 years+ of support for vulnerabilities, while at the same time not requiring the developers to extended support for multiple minor releases. I'll now go put on my asbestos undergarments and sit in the corner. ;-) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Freebsd custom installation cd
I added kernel configuration as attachment. When I boot system via freebsd live cd at boot process hptrr: no controller detected. acd0:DVDR at ata2-master UDMA66 ad16: 476938MB Samsung HD501LJ CR100-12 at ata8-master SATA300 then everthing is ok. but when I boot via custom installation cd; ad16 is not listed at boot screen. then saying no disk at fdisk section. I think there is missing kernel module but I couldnt find it. Date: Sat, 20 Sep 2008 15:53:14 -0700 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] CC: freebsd-stable@freebsd.org Subject: Re: Freebsd custom installation cd On Sun, Sep 21, 2008 at 01:20:51AM +0300, yusuf özbilgin wrote: Hello, I created custom freebsd installation cd with custom kernel. When I boot system with custom cd; kernel detects Intel ICH9 sata300 controller but end of the bootingit doesnt detect my sata disk. When you say it doesn't detect my SATA disk, what do you mean? Does the system lock up after saying Mounting root from...? Please let me know -- it's very important. Mainboard is intel and chipset is i965. There is no problem when I use this custom cd with gigabyte p35 chipset mainboard with same sata disk When I use the freebsd live cdit detects atapci0 Marvell 88SX6101 and atapci1 Intel Ahci Controller then it detects disk without problem. My kernel conf file is below. No one can read your kernel configuration because what you posted lacks newlines. Additionally, you said you're using a custom FreeBSD installation CD, which may be part of the problem as well (since you admit the Live CD works fine). -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] cpu I486_CPU cpu I586_CPU cpu I686_CPU ident FREEBSD-CDBOOT # To statically compile in device wiring instead of /boot/device.hints #hints GENERIC.hints # Default places to look for devices. #makeoptionsDEBUG=-g# Build kernel with gdb(1) debug symbols options SCHED_4BSD # 4BSD scheduler options PREEMPTION # Enable kernel thread preemption options INET# InterNETworking #optionsINET6 # IPv6 communications protocols #optionsSCTP# Stream Control Transmission Protocol options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories #optionsUFS_GJOURNAL# Enable gjournal-based UFS journaling options MD_ROOT # MD is a potential root device options MD_ROOT_SIZE=3 options NFSCLIENT # Network Filesystem Client #optionsNFSSERVER # Network Filesystem Server options NFS_ROOT# NFS usable as /, requires NFSCLIENT options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS# Pseudo-filesystem framework options GEOM_PART_GPT # GUID Partition Tables. options GEOM_LABEL # Provides labelization options COMPAT_43TTY# BSD 4.3 TTY compat [KEEP THIS!] options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options COMPAT_FREEBSD6 # Compatible with FreeBSD6 options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options KBD_INSTALL_CDEV# install a CDEV entry in /dev options ADAPTIVE_GIANT # Giant mutex is adaptive. options STOP_NMI# Stop CPUS using NMI instead of IPI #optionsAUDIT # Security event auditing #options QUOTA #options IPFIREWALL #options IPFIREWALL_VERBOSE #options IPFIREWALL_VERBOSE_LIMIT=5 #options IPFIREWALL_FORWARD #options IPFIREWALL_NAT
Re: Upcoming Releases Schedule...
On 21/09/2008, at 10:34 AM, netgeek wrote: Perhaps there is a middle ground here? What about a statement that each major branch (6.x, 7.x) will be supported for at least 24+ months from its last production release? Smaller periods of support could be given to minor releases along the way (7.2, for example), but at least companies would know that if they installed a 6.x version, they'd have support for a couple of years, even if that might mean upgrading to a newer minor version if there was a problem. This is already the case [1]. From each major branch one or more releases are designated as 'extended' and supported for 24 months. All you have to do is pick one of those and you've got support for 24 months. For example 6.3 has extended support in this way. RELENG_6 itself will be supported 24 months after the last release. Given roughly 18 months between major releases and about 12 months of ongoing releases from the previous branch after that, 4.5 years is roughly how long each major branch is supported for. That is already clear as could be. I can't quite understand what Jo Rhett is offering to the community that he is upset isn't being taken up. I think he wants some other arbitrary point release to be given extended support, either because in his case 24 months is not enough, or because he wants every release to have 24 months of support, or something else, I'm not sure. Jo, you say that he have had to maintain your own patched build of old FreeBSD releases because you need to keep them in production for longer than EoL period. Can I suggest that the first step is for you to publish those patches somewhere public and allow others to have access to them. Then you'll have a chance of convincing others to contribute to your patch sets and eventually of convincing FreeBSD to officially sanction them. Go and create a new sourceforge project or convince your boss to set aside some space on his web site/svn server/ etc for this project. Tell him that if it goes well, you'll be creating a whole lot of good will for the company in addition to the prospect of getting other people to contribute and share the work. Ari Maniatis [1] http://security.freebsd.org/ -- ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A ___ 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 hangs on boot w/Gigabyte MA78GM-S2H MB
On Sat, Sep 20, 2008 at 08:05:33AM -0700, Jeremy Chadwick wrote: On Sat, Sep 20, 2008 at 09:45:10AM -0500, Bob Willcox wrote: On Sat, Sep 20, 2008 at 07:04:56AM -0700, Jeremy Chadwick wrote: On Sat, Sep 20, 2008 at 08:24:29AM -0500, Bob Willcox wrote: 1) It would be helpful to know if you installed i386 or amd64 FreeBSD, This is amd64 on this particular machine. 2) With regards to the lock-up after mount root, if you press NumLock or CapsLock, do the keyboard LEDs turn on/off? Nope, no keys do anything. You must either push reset or pull the plug. Is it possible to get the output when booting in verbose mode? If not, what are the last few lines before the machine locks up when booting verbosely? Yep, just did that. The last things printed right before hang are: ioapic0: Assigning ISA IRQ 1 to local APIC 0 ioapic0: Assigning ISA IRQ 4 to local APIC 1 ioapic0: Assigning ISA IRQ 6 to local APIC 2 ioapic0: Assigning ISA IRQ 7 to local APIC 0 ioapic0: Assigning ISA IRQ 9 to local APIC 1 ioapic0: Assigning ISA IRQ 12 to local APIC 2 ioapic0: Assigning ISA IRQ 14 to local APIC 0 ioapic0: Assigning ISA PCI 16 to local APIC 1 ioapic0: Assigning ISA PCI 17 to local APIC 2 ioapic0: Assigning ISA PCI 18 to local APIC 0 ioapic0: Assigning ISA PCI 19 to local APIC 1 ioapic0: Assigning ISA PCI 22 to local APIC 2 trying to mount root from ufs:/dev/ad4s1a start_init: trying /sbin/init [hung at this point] 3) Many others have seen the hanging/lock-up after mount root. I believe one found a workaround by setting ATA_STATIC_ID in their kernel configuration. I realise this is a problem when you can't get the system up to a point of building a kernel; chicken-and-egg problem, Well, I can build a kernel if I run the 7.0-release kernel. That's how I got to 7-stable on the machine in the first place. I used sneaker net to copy it to this one via a CD (as I mentioned, the 7.0 kernel boots but the Realtek ethernet device is not recognized). So the problem is that 7.0-RELEASE works fine for you, but after upgrading your RELENG_7 source (to what is now 7.1-BETA), the machine hangs after printing the mount root message. Is this correct? Yes, that is pretty much it. The Realtek ethernet isn't working in in 7.0-RELEASE either, but I'm guessing that that is a different (and less serious) problem related to changes in that device. Here's another question: does booting into single-user exhibit the same problem as multi-user? It looks like when I try a single-user mode (and verbose) boot the only difference is that the las line shown above (the start_init line) isn't printed. Otherwise, the hang is the same. 4) The Realtek NIC on that motherboard is probably too new to be supported under RELENG_7. Realtek has a history of releasing different sub-revisions of the same NIC/PHY, and the internal changes are severe enough to cause the NIC to not work correctly (under any OS) without full driver support for that specific sub-revision. That's what I suspected. The values displayed when doing a pciconf -lv are similar as for this system I'm using to type this, but now that I look closer and make a direct comparison, the failing device has a rev=0x02 vs. rev=0x01 for the working one. The pciconf -lv output for the failing mb is: [EMAIL PROTECTED]:2:0:0: class=0x02 card=0xe0001458 chip=0x816810ec rev=0x02 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC' class = network subclass = ethernet Regarding the Realtek issue: I've CC'd PYUN Yong-Hyeon (surname in caps), who maintains the re(4) driver for FreeBSD. He might have a patch available for you to try, or help determine how to get this NIC working on FreeBSD. He'll probably need more than just pciconf -lv output, but should be able to work with you. Ok, that'd be great. I must say that I'm close to simply returning this MB and going with something not quite so new that is more likely to work. I was hoping to get this system up and running this weekend. :( I wish I knew what was causing the lock-up for you. I'm truly baffled, especially given that the system is able to boot + find the kernel + load kernel modules. Debugging this problem is out of field; jhb@ might have some ideas, as I'm not sure what magic happens immediately before the root filesystem is mounted. Those debugging/helping may want disklabel -r -A ad4s1 output. At least you can boot 7.0-RELEASE to get that information. Regarding hardware: I myself purchased an Asus P5Q SE board, with an
Re: freebsd 7 with sata drives
Brian wrote: The board in question is an Asus M3A78-EMH HDMI. I have tried the instructions for a safe kernel compile in /usr/src/updating also. Even after that, the kernel starts to load, but the root partition cant be found, and I am left at a mountroot prompt. If I go ufs:ad5s1a, that fails as well. Brian I have done much more testing on this. With a pata drive all is well. I can install 7.0-release and run freebsd-update successfully including the subsequent reboots. However, over the weekend I tried to go to stable again, and still, the subsequent reboot leaves me at a mountroot prompt. If I go ufs:ad8s1a at the prompt the root partition, of course I dont want to have to do this each time. If I use the september snapshot, the sata disk is visible. I just tried to run and iinstall a 6.4 prerelease, and then did a make buildworld make kernel KERNCONF=SMP and that worked successfully. I see this behavior with a 160 gig wd disk as well as a 74 gig raptor(This weekend's test hardware). Brian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
