Re: ia64 10-stable about r292594: rescue crunchide *.lo unknown executable format
> On Jan 27, 2016, at 12:32 AM, Anton Shterenlikht <me...@bris.ac.uk> wrote: > > I asked about this already in stable@ and ia64@. > Got no reply. Perhaps ia64 has been abandoned in > 10-stable too? If so, I'd like to know. > Hi Anton, I haven’t done anything with ia64 for over a year and frankly I lack the time to catch up and fix stuff. So, yeah, maybe just consider ia64 abandoned. FYI, -- Marcel Moolenaar mar...@xcllnt.net signature.asc Description: Message signed with OpenPGP using GPGMail
Re: ia64 stable/10 r286316: hang at Entering /boot/kernel/kernel
> On Sep 6, 2015, at 11:48 PM, Peter Wemm <pe...@wemm.org> wrote: > > This thread reminds me of what happened to eris.freebsd.org - removing DDB > from the kernel solved it for us in the freebsd.org cluster. It would be good to know if increasing the relocation array addresses the issue. If yes, I’d like to make that change. -- Marcel Moolenaar mar...@xcllnt.net signature.asc Description: Message signed with OpenPGP using GPGMail
Re: ia64 stable/10 r286316: hang at Entering /boot/kernel/kernel
> On Sep 2, 2015, at 10:30 AM, Anton Shterenlikht <me...@bris.ac.uk> wrote: > > The kernel limits I have in /boot/loader.conf > are following this PR: > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=156900 > > #kern.dfldsiz=536748032 # default soft limit for process data > #kern.dflssiz=536748032 # default soft limit for stack > # hard limits > #kern.maxdsiz=536748032 # hard limit for process data > #kern.maxssiz=536748032 # hard limit for stack > #kern.maxtsiz=536748032 # hard limit for text size > > If I leave these in, then with Marcel's patch > I get to mountroot> prompt, and then panic. To be clear: with the limits and without my patch you can’t even boot right? > > If I remove these, then I can boot. > > If I try booting with -s, then I get to a hang at > "Entering /boot/kernel”: Is this with or without limits? And is this with or without patch? > > /boot/kernel.old/kernel text=0x1110710 data=0xdfce8+0xa54f8 > syms=[0x8+0xc29e8+0x8+0xb78f6] > ?[37m?[44mBooting...?[m > Entering /boot/kernel.old/kernel at 0x9ffc00010500... > *** > * ROM Version : 04.29 > * ROM Date: 11/30/2007 > * BMC Version : 04.04 This is not a hang. This is a machine check. > > Is it worth investigating what limit value will boot? I’m inclined to say that it’s best to remove the limits altogether and just work with the default. If you need different default, add them to your kernel configuration. Set MAXTSIZ, DFLDSIZ, MAXDSIZ, DFLSSIZ and MAXSSIZ accordingly. Since you lower maxdsiz and maxssiz from 1G to 512M, you can safely leave them as is (unless you tend to have runaway processes :-) You increase maxssiz from 256M to 512M, which you probably want to keep doing to make sure you can run the same set of processes as you do now. At this point in time, the only fix I’m willing to make is for the size of the array that holds relocations. If it made things better, I’ll commit it. If it didn’t, then I’m not going to commit it. Anything more involved will take more time than I’m willing to put into ia64 at this time... Sorry, -- Marcel Moolenaar mar...@xcllnt.net signature.asc Description: Message signed with OpenPGP using GPGMail
Re: ia64 stable/10 r286316: hang at Entering /boot/kernel/kernel
On Aug 28, 2015, at 3:35 AM, Konstantin Belousov kostik...@gmail.com wrote: Might be, try the latest stable/10 kernel with the problematic revision r286316 reversed ? This might add more points to the Marcel' note about some static relocation table processed early. I built a kernel off of revision 286315 and got this: eris% objdump -R kernel | grep FPTR64LSB | wc -l 5377 We only reserve room for 4096 relocations, so we’re over as it is. A kernel off of revision 286316 gave me this: eris% objdump -R kernel | grep FPTR64LSB | wc -l 5377 Same. Odd, but ok. It’s possible that the memory layout changed such that we now scribble over something that’s important. To be sure: Anton can you apply the following patch and tell me if it makes a difference. It doubles the space we set aside for relocations. Index: sys/ia64/ia64/locore.S === --- sys/ia64/ia64/locore.S (revision 286316) +++ sys/ia64/ia64/locore.S (working copy) @@ -357,5 +357,5 @@ .align 16 .global fptr_storage fptr_storage: - .space 4096*16 // XXX + .space 8192*16 // XXX fptr_storage_end: -- Marcel Moolenaar mar...@xcllnt.net signature.asc Description: Message signed with OpenPGP using GPGMail
Re: ia64 stable/10 r286316: hang at Entering /boot/kernel/kernel
On Aug 27, 2015, at 9:23 AM, Konstantin Belousov kostik...@gmail.com wrote: On Thu, Aug 27, 2015 at 01:12:16PM +0100, Anton Shterenlikht wrote: ia64 stable/10 r286315 boots, but r286316 hangs at Entering /boot/kernel/kernel. Please advise To state an obvious thing. The commit which you pointed to, changes the code which is not executed at that early kernel boot stage. The revision cannot cause the consequences you described. Failures may not always be obvious. The ia64 kernel has a fixed array for relocations and a harmless piece of code, which may actually never be called, could result in additional relocations that case the array to overflow and do bad things on boot. All I’m saying is: give Anton the benefit of the doubt. He has spent a lot of time with ia64 and knows quite a bit about its behavior. We simply do not know what’s going on and he has provided us with a lead. We go from there... -- Marcel Moolenaar mar...@xcllnt.net signature.asc Description: Message signed with OpenPGP using GPGMail
Re: ia64 regression from r285809 to 286952: kernel does not boot
On Aug 23, 2015, at 7:51 AM, Anton Shterenlikht me...@bris.ac.uk wrote: I'm not sure if ia64 list is still operational, so post here. ia64 r285809 10-STABLE works fine. I updated to r286952, buildworld, buildkernel, installkernel, reboot, boot -s, and I get stuck with: FreeBSD/ia64 EFI boot, Revision 3.0 (r...@mech-cluster241.men.bris.ac.uk, Thu May 5 11:18:40 BST 2011) Loading /boot/defaults/loader.conf /boot/kernel/kernel text=0x11107f0 data=0xdfd68+0xa54f8 syms=[0x8+0xc2a78+0x8+0xb7965] - Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... Entering /boot/kernel/kernel at 0x9ffc00010500… Do you have options DDB in your kernel configuration? If yes, can you boot without it? -- Marcel Moolenaar mar...@xcllnt.net signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Serial multiport error Oxford/Startech PEX2S952
On Aug 24, 2011, at 4:59 AM, Jeremy Chadwick wrote: It may also be interesting to try 9.x on a machine with a serial port that operates directly with uart(4). Does stty(4) throw up isn't a terminal errors against the .init and .lock devices relating to those ports? I would try this myself, but am very short of time at present. Though there is probably little more that I can add, please keep me cc'd on all relevant e-mails, especially as I do not follow freebsd-current. I'm CC'ing Marcel Moolenaar here, who's the author of uart(4), to help assist in this matter and shed some light on the above comments. If there's a quirk or bug there, I'm certain he'll assist in helping. There's no obvious problem in uart(4). The handling of *.init and *.lock is all unified in the TTY layer. Note that the typical scenario for uart(4) to not respect the baud rate setting is when the UART port is a system device (i.e. serial console or debug port). Make sure there's no difference between 8.x and 9.x with respect to which ports are declared as system ports. FYI, -- Marcel Moolenaar mar...@xcllnt.net ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Bring sio up to 8+
On May 22, 2011, at 4:58 AM, Lars Eighner wrote: It seems increasing unlikely that uart will ever support the only internal hardware modem recently available in the US (PR kern/155196), so what are the chances of sio (which works in 7.x reasonably well and better with a one-line hack) being brought forward? The PR states that uart(4) basically works, but that reconnecting on demand doesn't. What makes you think this is a problem with uart(4) and not with the TTY overhaul? -- Marcel Moolenaar mar...@xcllnt.net ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: RFC vgrind in base (and buildworld)
On Jan 21, 2011, at 7:25 AM, Alexander Kabaev wrote: On Thu, 20 Jan 2011 17:11:13 -0800 Marcel Moolenaar xcl...@mac.com wrote: On Jan 20, 2011, at 12:31 PM, Alexander Kabaev wrote: On Thu, 20 Jan 2011 21:17:40 +0100 Ulrich Spörlein u...@freebsd.org wrote: Hello, Currently our buildworld relies on groff(1) and vgrind(1) being present in the host system. I have a patch ready that at least makes sure these are built during bootstrap-tools and completes the WITHOUT_GROFF flag. vgrind(1) is only used for two papers under share/doc and we could easily expand the results and commit them to svn directly, alleviating the need to run vgrind(1) during buildworld. OTOH, there are much more useful tools to vgrind(1) for source code formatting. So do we still have vgrind(1) users out there? Regards, Uli Why it needs to be in bootsrap tools at all? We have build tools for this exact purpose. Actually no. The buildtools target is there to allow building programs that are not installed, but are otehrwise needed to compile a program. These are typically little tools that create source files. The bootstrap target is the to deal with compatibility in case we can't use the version on the host or we don't want to depend on the version on the host. Then it is cross-tools, or whatever build stage that builds new gcc and other tools which run on host and are used to generate the final target binaries. Cross-tools is what you say. Anything that has target architecture neutral output should therefore not be build all the time as part of cross-tools. The point being that bootstrap-tools target is greatly abused in src, with recent addition of llvm libs making it almost pandemic. Yes, I can see bootstrap tools being abused. It started being abused the moment it came to live :-) But rather than abuse the other targets, I'm more inclined to review our build system and see if we need to start making big changes again. In particular: Juniper is ramping up on stock FreeBSD development and the first thing we ran into is that FreeBSD doesn't have a good cross-development and cross-build environment. We have hacks so that we don't have to say we don't have it at all, but one cannot possibly believe that what we have is good. So, let's get everything on the table and look for ways to improve things structurally rather than using ad-hoc or one- off tweaks. Is there value in having FreeBSD development ports that one can install on a machine and thereby making it suitable for FreeBSD (cross-) development? In other words: do people mind if there's a one-time setup (or upgrade) required before being able to build FreeBSD? What if this is done automatically as part of buildworld (i.e. installing or upgrading a port)? If not, then we can get rid of bootstrap-tools altogether. If the port also includes (cross-compilers) we can also rid ourselves of cross-tools and end up with a good cross-devel environment in the process. Thoughts? -- Marcel Moolenaar xcl...@mac.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: RFC vgrind in base (and buildworld)
On Jan 20, 2011, at 12:31 PM, Alexander Kabaev wrote: On Thu, 20 Jan 2011 21:17:40 +0100 Ulrich Spörlein u...@freebsd.org wrote: Hello, Currently our buildworld relies on groff(1) and vgrind(1) being present in the host system. I have a patch ready that at least makes sure these are built during bootstrap-tools and completes the WITHOUT_GROFF flag. vgrind(1) is only used for two papers under share/doc and we could easily expand the results and commit them to svn directly, alleviating the need to run vgrind(1) during buildworld. OTOH, there are much more useful tools to vgrind(1) for source code formatting. So do we still have vgrind(1) users out there? Regards, Uli Why it needs to be in bootsrap tools at all? We have build tools for this exact purpose. Actually no. The buildtools target is there to allow building programs that are not installed, but are otehrwise needed to compile a program. These are typically little tools that create source files. The bootstrap target is the to deal with compatibility in case we can't use the version on the host or we don't want to depend on the version on the host. -- Marcel Moolenaar xcl...@mac.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 8.x grudges
On Jul 7, 2010, at 1:34 PM, Randi Harper wrote: Well, pardon the political pun, but I don't believe in change for the sake of change. These particular changes are gratuitous. If sio is no longer available -- and replaced by uart, why change the /dev-entries?.. These changes aren't gratuitous. Did you read the commit messages behind each of the changes? I'm guessing that you haven't. Not to mention that if you change uart(4) to create dev entries like sio(4) after uart(4) has been in the tree for more than 6 years creating ttyu* entries, you actually introduce a gratuitous change. It's all about perspective... -- Marcel Moolenaar xcl...@mac.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: puc(4) timedia baudrate problem
On Apr 27, 2010, at 10:10 PM, Artem Belevich wrote: I've got another PCI UART card based on OX16PCI952 that needs its clock multiplied by 8 in order to work correctly. It was some el-cheapo card I've got at Fry's. p...@pci0:1:0:0:class=0x070006 card=0x00011415 chip=0x95211415 rev=0x00 hdr=0x00 vendor = 'Oxford Semiconductor Ltd' device = 'OX16PCI952 Integrated Dual UART' class = simple comms subclass = UART bar [10] = type I/O Port, range 32, base 0xd480, size 8, enabled bar [14] = type I/O Port, range 32, base 0xd400, size 8, enabled bar [18] = type I/O Port, range 32, base 0xd080, size 32, enabled bar [1c] = type Memory, range 32, base 0xf9ffd000, size 4096, enabled bar [20] = type Memory, range 32, base 0xf9ffc000, size 4096, enabled Perhaps we can add some sort of tunable to override UART clock, if necessary? That's a good idea. I've seen with the Oxford that the RCLK can different even for the same vendor/device ID. There's no way for us to do the right thing. This may also be the case for Timedia chipsets... -- Marcel Moolenaar xcl...@mac.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: puc(4) timedia baudrate problem
On Apr 27, 2010, at 12:47 PM, Paul Schenkeveld wrote: puc0: Timedia technology 8 Port Serial port 0xe500-0xe51f,0xe520-0xe52f,0xe530-0xe537,0xe538-0xe53f,0xe540-0xe547,0xe548-0xe54f irq 10 at device 14.0 on pci0 *snip* The first two ports work correctly but the baudrate of the other six is incorrect, i.e. I have to use 'tip -76800 uart5' to get the port to communicate at 9600 baud. I 'know' that this particular hardware has a baudrate multiplier on the first two ports but not on the other six. *snip* Can you show me the output of ``pciconf -lbv'' for this device so that I can create a patch for you to test? Also: do you happen to know if all 8-port Timedia cards have a non- uniform RCLK or only a select set (maybe only yours)? Thanks, -- Marcel Moolenaar xcl...@mac.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
8-stable/amd64: ATA: hard hang when doing burncd fixate
All, I get a hard hang on a TYAN Thunder K8S with a single Opteron mounted: : CPU: AMD Opteron(tm) Processor 246 (1991.62-MHz K8-class CPU) Origin = AuthenticAMD Id = 0xf58 Stepping = 8 Features=0x78bfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2 AMD Features=0xe0500800SYSCALL,NX,MMX+,LM,3DNow!+,3DNow! real memory = 1073741824 (1024 MB) avail memory = 1023348736 (975 MB) ACPI APIC Table: A M I OEMAPIC : atapci0: SiI 3114 SATA150 controller port 0xbc00-0xbc07,0xb880-0xb883,0xb800-0xb807,0xac00-0xac03,0xa880-0xa88f mem 0xfeafec00-0xfeafefff irq 19 at device 5.0 on pci3 atapci0: [ITHREAD] ata2: ATA channel 0 on atapci0 ata2: [ITHREAD] ata3: ATA channel 1 on atapci0 ata3: [ITHREAD] ata4: ATA channel 2 on atapci0 ata4: [ITHREAD] ata5: ATA channel 3 on atapci0 ata5: [ITHREAD] : atapci1: AMD 8111 UDMA133 controller port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 7.1 on pci0 ata0: ATA channel 0 on atapci1 ata0: [ITHREAD] ata1: ATA channel 1 on atapci1 ata1: [ITHREAD] : atapci2: Marvell 88SX6081 SATA300 controller port 0x8800-0x88ff mem 0xfc80-0xfc8f irq 26 at device 2.0 on pci2 atapci2: [ITHREAD] ata6: ATA channel 0 on atapci2 ata6: [ITHREAD] ata7: ATA channel 1 on atapci2 ata7: [ITHREAD] ata8: ATA channel 2 on atapci2 ata8: [ITHREAD] ata9: ATA channel 3 on atapci2 ata9: [ITHREAD] ata10: ATA channel 4 on atapci2 ata10: [ITHREAD] ata11: ATA channel 5 on atapci2 ata11: [ITHREAD] ata12: ATA channel 6 on atapci2 ata12: [ITHREAD] ata13: ATA channel 7 on atapci2 ata13: [ITHREAD] : acd0: DVDR NEC DVD+/-RW ND-6500A/2.22 at ata1-master UDMA33 ad0: 476940MB Maxtor 7H500F0 HA431DN0 at ata2-master UDMA100 SATA 1.5Gb/s ad1: 476940MB Maxtor 7H500F0 HA431DN0 at ata3-master UDMA100 SATA 1.5Gb/s ad2: 1430799MB Seagate ST31500341AS SD17 at ata6-master UDMA100 SATA 3Gb/s ad3: 1430799MB Seagate ST31500341AS CC1H at ata7-master UDMA100 SATA 3Gb/s ad4: 476940MB MAXTOR STM3500630AS 3.AAE at ata12-master UDMA100 SATA 1.5Gb/s : Writing an image is fine using: ns1% sudo burncd -f /dev/acd0 data FreeBSD-9.0-CURRENT-201001-ia64-bootonly.iso Fixating the CD is causing the hard hang: ns1% sudo burncd -f /dev/acd0 fixate fixating CD, please wait.. *hard hang* There's nothing in the console and interrupts are all masked. A power-cycle is the only thing that can be done. Is this a known issue? -- Marcel Moolenaar xcl...@mac.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: update to 8.0-RELEASE -- partition gone
On Dec 16, 2009, at 3:27 AM, Marian Hettwer wrote: gee, thanks! That worked. r...@talisker:/root# ls /dev/ad8* /dev/ad8/dev/ad8s1 /dev/ad8s1a r...@talisker:/root# mount /dev/ad8s1a /BACKUP/ r...@talisker:/root# umount /BACKUP/ but, hm, whats that? r...@talisker:/root# fsck /dev/ad8s1a fsck: Could not determine filesystem type I minor inconvenience for the time being. fsck hasn't been thought about getting partition types from gpart, so that it can do a best-effort attempt at guessing which variant to run. For now, you need to be explicit: fsck -t ufs /dev/ad0s1a Alternatively, add an entry to /etc/fstab. FYI, -- Marcel Moolenaar xcl...@mac.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: update to 8.0-RELEASE -- partition gone
On Dec 16, 2009, at 2:33 AM, sth...@nethelp.no wrote:
If you installed dangerously dedicated and ended up
with ad0s1a (note the s1), then you have an invalid
partitioning and FreeBSD 8.x will not give you what
you've been getting on FreeBSD 7.x. Most of the time
you only need to wipe out the second sector on the
disk to clean it up and have FreeBSD 8.x also give
you ad0s1a.
So what's an easy recipe we can run on 7.x hosts to see whether we
would have problems with 8.x?
If
1. fdisk ${D} shows FreeBSD slices, and
2. your mount points are within these slices (i.e your device name
has a prefix of ${D}s1, ${D}s2, ${D}s3, etc *OR* they have a
prefix of ${D}cs1 ${D}cs2 ${D}cs3, etc), and
3. bsdlabel ${D} shows that there's a (possibly empty) BSD disklabel
then you have an invalidly created danerously dedicated disk.
You can wipe out the second sector on the disk to clear the bogus
BSD disklabel.
The most important thing to look at is how you currently mount.
If fdisk ${D} and bsdlabel ${D} show valid information and you
mount from ${D}a, ${D}d, etc -- then your disk is not necessarily
invalid in the same sense that having a PMBR with slices in front
of a GPT is not considered invalid.
FYI,
--
Marcel Moolenaar
xcl...@mac.com
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: PUC Serial I/O problem - copy of gnats-filed bug report (as [SB QUAR: Sun Dec 13 10:50:06 2009] discussed previously)
On Dec 15, 2009, at 7:03 AM, Karl Denninger wrote: This is now marked fixed and it appears (after limited testing thus far) that it indeed is. The bug existed in 7 as well. It's not a regression introduced in 8. The reason why this didn't come up in the 7 time frame is that sio(4) was still the default. Jeremy has been an early adopter of uart(4) and if I'm not mistaken, he always loaded the driver(s) as modules. This, due to a lucky bug, avoided the problem for him. In depth: With uart(4) I created the serdev I/F. This is an interface that allows umbrella drivers like puc(4) and scc(4) to obtain pending interrupt status and invoke interrupt source specific handlers. This puts the umbrella driver in control over what gets handled in what order *across* multiple interfaces. As such, with puc(4), you can service all receive interrupts for all ports before you service, say, the transmit interrupt across the ports. When a serial device does not implement the serdev I/F, then puc(4) won't be involved in interrupt handling at all. This is why puc(4)+sio(4) had no problem. Since uart(4) does implement the serdev I/F, the interrupt handler of puc(4) would be in control and since it was this interrupt handler that was broken, exhibit the stalls. But, when puc(4) and/or uart(4) were loaded as modules, puc(4) would not see uart(4) as implementing the serdev I/F. This is to do with linker sets, etc. Consequently, uart(4) would handle its own interrupts and puc(4) would not be involved (just as with the sio(4) setup). In that scenario puc(4)+uart(4) also just worked. In any case: puc(4) has been fixed and I'll deal with the linker set bug later. For best results: compile puc(4) and uart(4) into the kernel and don't load them as modules for now... FYI, -- Marcel Moolenaar xcl...@mac.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: PUC Serial I/O problem - copy of gnats-filed bug report (as [SB QUAR: Sun Dec 13 10:50:06 2009] discussed previously)
On Dec 15, 2009, at 10:36 AM, Jeremy Chadwick wrote: Thanks for fixing the problem Karl's reported. As I've stated in the past, I appreciate your efforts and attentiveness to this sort of thing. If there's any way I can repay you (Paypal donations, etc.), just let me know and I'll do what I can. Don't worry about me. If people like to do something in return for what I did, I would like them to donate towards the ports cluster in general or Mark Linimon (lini...@freebsd.org) in particular. Mark also puts in a lot of effort to get our bug database in a decent state, so he's the guy to reward. FYI, -- Marcel Moolenaar xcl...@mac.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: update to 8.0-RELEASE -- partition gone
On Dec 15, 2009, at 2:20 PM, Steven Friedrich wrote: FreeBSD 8.0 no longer supports dangerously dedicated disks. This is not true. The problem is that sysinstall creates an invalid dangerously dedicated disk, as demonstrated by doing: # fdisk ad8 (shows FreeBSD slice information) # bsdlabel ad8 (shows valid but empty disk label) Marian just needs to wipe out the second sector on the disk to remove the BSD disklabel that prevents the kernel from using the master boot record in the 1st sector. This exposes ad8s1. This then will pick up the BSD disklabel in sector 65 (i.e. the second sector in slice 1) to give ad8s1a... fdisk output appears to indicate that your disk has a partition table, but I never looked at one with fdisk that was dedicated... fdisk may or may not show partitions. Typically there should not be any, because it's the disklabel in sector 2 that holds the partition information. The MBR in the first sector is there only for the BIOS: you can't boot without one. -- Marcel Moolenaar xcl...@mac.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: update to 8.0-RELEASE -- partition gone
On Dec 15, 2009, at 4:08 PM, Ben Morrow wrote:
Quoth Marcel Moolenaar xcl...@mac.com:
On Dec 15, 2009, at 2:20 PM, Steven Friedrich wrote:
FreeBSD 8.0 no longer supports dangerously dedicated disks.
This is not true. The problem is that sysinstall creates an invalid
dangerously dedicated disk, as demonstrated by doing:
# fdisk ad8
(shows FreeBSD slice information)
# bsdlabel ad8
(shows valid but empty disk label)
Marian just needs to wipe out the second sector on the disk to
remove the BSD disklabel that prevents the kernel from using
the master boot record in the 1st sector. This exposes ad8s1.
This then will pick up the BSD disklabel in sector 65 (i.e.
the second sector in slice 1) to give ad8s1a...
Are you able to clarify exactly what is no longer working in 8?
Everything is working, but behaviour has changed for invalid
disks. Invalid disks are disks with conflicting partitioning
information. In FreeBSD 8.x the behaviour is deterministic
and for the broken dangerously dedicated disks that sysinstall
creates this means that we use the partition information in
the BSD disklabel. In FreeBSD 7.x this could come from either
the MBR or the BSD disklabel, with the MBR the more common
scenario.
You seem
to be implying here that there is only a problem if there are invalid
and/or overlapping labels on the disk; elsewhere I have read that disks
without an MBR aren't supported at all (I presume the faked-up MBR on a
GPT disk counts).
Disks without an MBR are supported.
If I currently have a working ad2{b,c,d,e}, will they
be picked up by 8, or would I have to repartition slightly smaller with
a useless MBR slice in front?
Yes, if you have ad2a and not ad2s1a, then you have a
proper dangerously dedicated disk and FreeBSD 8.x will
work correctly with your disk.
If you installed dangerously dedicated and ended up
with ad0s1a (note the s1), then you have an invalid
partitioning and FreeBSD 8.x will not give you what
you've been getting on FreeBSD 7.x. Most of the time
you only need to wipe out the second sector on the
disk to clean it up and have FreeBSD 8.x also give
you ad0s1a.
--
Marcel Moolenaar
xcl...@mac.com
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: uart(4) on stable/7
On Oct 26, 2009, at 2:57 PM, Matthew Fleming wrote: I can ssh to my box, echo to /dev/console appears on the console; messages on reboot appear on the console, just not the login prompt. Does anyone know what else I may be missing to use uart(4)? As Andrew pointed put, you need to update /etc/ttys as well. Also, we have some boot scripts locally that will try to set machdep.conspeed based on hardware type; uart(4) doesn't seem to expose a sysctl by that name. How does the uart driver for stable/7 deal with differing console speeds? uart(4) has 2 approaches for this: 1) you don't specify a speed -- in this case uart(4) will simply re-use the speed that hardware is programmed for. 2) You do specify a speed - uart(4) will reprogram the the console speed based on the hw.uart.console tunable. Note that for compatibility with sio(4) hints can be used as well. Use hint.uart.0.baud=9600 to set the console speed to 9600 baud. There's no compiled-in console speed. The compiled-in default (in a way) is to use the speed the hardware is programmed for. -- Marcel Moolenaar xcl...@mac.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
8.0-RC1: kernel page fault in NLM master thread (VIMAGE or ZFS related?)
All,
I just got this overnight on my server:
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x90
fault code = supervisor read, page not present
instruction pointer = 0x20:0xc05ba39d
stack pointer = 0x28:0xf31077bc
frame pointer = 0x28:0xf31077c8
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 928 (NLM: master)
(kgdb) bt
#0 doadump () at pcpu.h:246
#1 0xc05e03f3 in boot (howto=260) at /zmirror/nfs/freebsd/base/stable/
8/sys/kern/kern_shutdown.c:416
#2 0xc05e062d in panic (fmt=Variable fmt is not available.
) at /zmirror/nfs/freebsd/base/stable/8/sys/kern/kern_shutdown.c:579
#3 0xc04ac807 in db_panic (addr=Could not find the frame base for
db_panic.
) at /zmirror/nfs/freebsd/base/stable/8/sys/ddb/db_command.c:478
#4 0xc04acd91 in db_command (last_cmdp=0xc0881c3c, cmd_table=0x0,
dopager=1) at /zmirror/nfs/freebsd/base/stable/8/sys/ddb/db_command.c:
445
#5 0xc04aceea in db_command_loop () at /zmirror/nfs/freebsd/base/
stable/8/sys/ddb/db_command.c:498
#6 0xc04aed5d in db_trap (type=12, code=0) at /zmirror/nfs/freebsd/
base/stable/8/sys/ddb/db_main.c:229
#7 0xc0608a14 in kdb_trap (type=12, code=0, tf=0xf310777c) at /
zmirror/nfs/freebsd/base/stable/8/sys/kern/subr_kdb.c:535
#8 0xc07c53af in trap_fatal (frame=0xf310777c, eva=144) at /zmirror/
nfs/freebsd/base/stable/8/sys/i386/i386/trap.c:924
#9 0xc07c5650 in trap_pfault (frame=0xf310777c, usermode=0, eva=144)
at /zmirror/nfs/freebsd/base/stable/8/sys/i386/i386/trap.c:846
#10 0xc07c5ff2 in trap (frame=0xf310777c) at /zmirror/nfs/freebsd/base/
stable/8/sys/i386/i386/trap.c:528
#11 0xc07ac50b in calltrap () at /zmirror/nfs/freebsd/base/stable/8/
sys/i386/i386/exception.s:165
#12 0xc05ba39d in prison_priv_check (cred=0xc61e4880, priv=334) at /
zmirror/nfs/freebsd/base/stable/8/sys/kern/kern_jail.c:3568
#13 0xc05d39ee in priv_check_cred (cred=0xc61e4880, priv=334, flags=0)
at /zmirror/nfs/freebsd/base/stable/8/sys/kern/kern_priv.c:92
#14 0xc09dbffc in secpolicy_fs_owner (mp=0xc4112284, cred=0xc61e4880)
at /zmirror/nfs/freebsd/base/stable/8/sys/modules/zfs/../../cddl/
compat/opensolaris/kern/opensolaris_policy.c:86
#15 0xc09dc527 in secpolicy_vnode_access (cred=0xc61e4880,
vp=0xc4bb6d9c, owner=501, accmode=128)
at /zmirror/nfs/freebsd/base/stable/8/sys/modules/zfs/../../cddl/
compat/opensolaris/kern/opensolaris_policy.c:125
#16 0xc0a56c5c in zfs_zaccess (zp=0xd4be8658, mode=2, flags=Variable
flags is not available.
) at /zmirror/nfs/freebsd/base/stable/8/sys/modules/zfs/../../cddl/
contrib/opensolaris/uts/common/fs/zfs/zfs_acl.c:2445
#17 0xc0a56edb in zfs_zaccess_rwx (zp=0xd4be8658, mode=Variable mode
is not available.
) at /zmirror/nfs/freebsd/base/stable/8/sys/modules/zfs/../../cddl/
contrib/opensolaris/uts/common/fs/zfs/zfs_acl.c:2484
#18 0xc0a6bfa4 in zfs_freebsd_access (ap=0xf31078d4) at /zmirror/nfs/
freebsd/base/stable/8/sys/modules/zfs/../../cddl/contrib/opensolaris/
uts/common/fs/zfs/zfs_vnops.c:1068
#19 0xc07cfeb2 in VOP_ACCESS_APV (vop=0xc0acfac0, a=0xf31078d4) at
vnode_if.c:571
#20 0xc0718c93 in nlm_get_vfs_state (host=Variable host is not
available.
) at vnode_if.h:254
#21 0xc0718e30 in nlm_do_unlock (argp=0xf31079c8, result=0xf3107a08,
rqstp=0xcb199800, rpcp=0x0) at /zmirror/nfs/freebsd/base/stable/8/sys/
nlm/nlm_prot_impl.c:2227
#22 0xc071ac87 in nlm4_unlock_4_svc (argp=0xf31079c8,
result=0xf3107a08, rqstp=0xcb199800) at /zmirror/nfs/freebsd/base/
stable/8/sys/nlm/nlm_prot_server.c:540
#23 0xc071bce3 in nlm_prog_4 (rqstp=0xcb199800, transp=0xc652de00) at /
zmirror/nfs/freebsd/base/stable/8/sys/nlm/nlm_prot_svc.c:512
#24 0xc07284bf in svc_run_internal (pool=0xc61e4c80, ismaster=1) at /
zmirror/nfs/freebsd/base/stable/8/sys/rpc/svc.c:893
#25 0xc072943d in svc_run (pool=0xc61e4c80) at /zmirror/nfs/freebsd/
base/stable/8/sys/rpc/svc.c:1233
#26 0xc071a348 in nlm_syscall (td=0xc6551000, uap=0xf3107cf8) at /
zmirror/nfs/freebsd/base/stable/8/sys/nlm/nlm_prot_impl.c:1593
#27 0xc07c5977 in syscall (frame=0xf3107d38) at /zmirror/nfs/freebsd/
base/stable/8/sys/i386/i386/trap.c:1073
#28 0xc07ac570 in Xint0x80_syscall () at /zmirror/nfs/freebsd/base/
stable/8/sys/i386/i386/exception.s:261
#29 0x0033 in ?? ()
(kgdb) frame 12
#12 0xc05ba39d in prison_priv_check (cred=0xc61e4880, priv=334) at /
zmirror/nfs/freebsd/base/stable/8/sys/kern/kern_jail.c:3568
3568switch (priv) {
(kgdb) l 3567
3562 */
3563if (cred-cr_prison-pr_flags PR_VNET)
3564return (0);
3565}
3566#endif /* VIMAGE */
3567
3568switch (priv) {
3569
3570/*
3571 * Allow ktrace privileges for root in jail.
(kgdb) p cred-cr_prison
$4 = (struct prison *) 0x0
--
Marcel
Re: 8.0-RC1: kernel page fault in NLM master thread (VIMAGE or ZFS related?)
On Sep 25, 2009, at 4:01 PM, Jamie Gritton wrote: (kgdb) p cred-cr_prison $4 = (struct prison *) 0x0 It seems to be NFS related. I think the null pointer in question is from the export's anonymous credential. Try the patch below and see if it helps (which I guess means run it overnight and see if it crashes again). Thanks. I'll give it a spin... -- Marcel Moolenaar xcl...@mac.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: IA64 7.2-RC2 in HP Integrity Virtual Machine
On May 6, 2009, at 7:30 AM, Zahemszky Gábor wrote: I believe there's a problem with mpt(4) that relates to its error recovery, or lack thereof. Can you send a backtrace so that we can confirm or de- bunk that statement? Hi! here it is. (sorry for the ESC-sequences, it is the virtual machine's EFI boot loader) Attached. Ok. It's not mpt(4). It looks like it's the VM itself that's the problem. The page fault is the result of a clobbered r17. Looking at the registers and the source code, as well as the assembly I conclude that writes to the region registers (which are virtualized) cause a trap in the VM and the context is not properly saved or restored. I conclude this based on r16 being 1 (we've had 1 iteration of the loop on line 2220 in file sys/ia64/ia64/pmap.c (assuming r16 is not clobbered). This means we had at least 1 write to the region register. r17 is initialized to (pm-pm_rid[0]) and since the load has a post-increment of 4, it walks the pm_rid array. It never has a value of 1. So, r17 must have been clobbered, because it's never assigned 1 in the program. So either the VM is buggy, or you need explicit support for the VM in the guest OS by design. FYI, -- Marcel Moolenaar xcl...@mac.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: IA64 7.2-RC2 in HP Integrity Virtual Machine
[CC to i...@freebsd.org] On Apr 28, 2009, at 11:38 PM, Zahemszky Gabor wrote: Hi! I've tried to install the new 7.2-RC2 FreeBSD version, on a HP-UX IVM (*) guest virtual machine. But I couldn't install it. With verbose boot, the only one I can get is: . (other devices) lo0: bpf attached Waiting 5 seconds for SCSI devices to settle (xpt0:mpt0:0:-1:-1): reset bus fatal kernel trap (cpu 0): trap vector = 0x14 (Page Not Present) cr.iip = 0xe4a1dba0 cr.ipsr = 0x1010080a2010 (mfl,ic,dt,dfh,rt,cpl=0,it,ri=0,bn) cr.isr = 0x804 (code=0,vector=0,r,ei=0,ed) cr.ifa = 0x1 curthread = 0xe4c1fa40 pid = 0, comm = swapper [thread pid 0 tid 0 ] Stopped at pmap_switch+0x120: [M0]ld4 r14=[r17],0x4 db I believe there's a problem with mpt(4) that relates to its error recovery, or lack thereof. Can you send a backtrace so that we can confirm or de- bunk that statement? thanks, -- Marcel Moolenaar xcl...@mac.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: the future of sun4v
On Aug 22, 2008, at 4:33 AM, Peter Jeremy wrote: [Replies re-directed to freebsd-sun4v] On 2008-Aug-21 14:42:55 -0700, Kip Macy [EMAIL PROTECTED] wrote: I believe that there is a general expectation by freebsd users and developers that unsupported code should not be in CVS. Although sun4v is a very interesting platform for developers doing SMP work, I simply do not have the time or energy to maintain it. If someone else would like to step up and try his hand I would be supportive of his efforts. In the likely event that no one steps forward by the time that 7.1 is released I will ask that it be moved to the Attic. Since there are no other current SPARC CPUs that FreeBSD can run on (the US-II has been obsolete for about 6 years and FreeBSD won't run on any more recent sun4u chips), that will also remove the justification for maintaining a SPARC64 port. Marius has been doing some great work towards US-III support. I have FreeBSD/sparc64 running on Netra SMP with US-III CPUs. While the code is not in SVN, It's in Perforce and from what I can see, it's in a very good shape. FYI, -- Marcel Moolenaar [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: Timedia 8 port serial pci card problem
On May 16, 2008, at 1:17 AM, Thomas Vogt wrote: FreeBSD detects it with: puc0: Timedia technology 8 Port Serial port 0xe500-0xe51f,0xe520-0xe52f,0xe530-0xe537,0xe538-0xe53f, 0xe540-0xe547,0xe548-0xe54f irq 10 at device 14.0 on pci0 . But it only adds 3 uart ports instead of 8. Any idea what i can do? Can you try the following (white-space corrupted) patch: Index: pucdata.c === RCS file: /home/ncvs/src/sys/dev/puc/pucdata.c,v retrieving revision 1.59.2.1 diff -u -r1.59.2.1 pucdata.c --- pucdata.c 26 Feb 2008 09:33:57 - 1.59.2.1 +++ pucdata.c 16 May 2008 10:48:25 - @@ -1116,7 +1116,7 @@ *res = (port == 1 || port == 3) ? 8 : 0; return (0); case PUC_CFG_GET_RID: - *res = 0x10 + ((port 3) ? port - 2 : port 1); + *res = 0x10 + ((port 3) ? port - 2 : port 1) * 4; return (0); case PUC_CFG_GET_TYPE: *res = PUC_TYPE_SERIAL; -- Marcel Moolenaar [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: PCI serial card works on 6.2 but not on 6.3
On May 6, 2008, at 6:05 AM, Ingeborg Hellemo wrote:
[EMAIL PROTECTED] said:
Try loading the uart(4) driver, which can also replace sio(4) if I
remember
correctly.
I have now tried both loading the uart4) -driver and kompiled it
into the
kernel, but the card is still unrecognized:
pci1: simple comms, UART at device 8.0 (no driver attached)
~# pciconf -l -v | grep -B 4 UART
[EMAIL PROTECTED]:8:0: class=0x070002 card=0x00041000 chip=0x98459710
rev=0x01
hdr=0x00
vendor = 'MosChip Semiconductors (Was: Netmos Technology)'
device = 'Nm9845 Parallel/Serial Port Adapter'
class = simple comms
subclass = UART
The problem seems to be puc(4). This appears to be a multi-port
card, which means puc(4) needs to attach. This is not happening.
The problem seems to be revision 1.51.2.3 of src/sys/dev/puc/pucdata.c
Could you try the following patch?
Index: pucdata.c
===
RCS file: /volume/apg-bbuild09-b/marcelm/ncvs/src/sys/dev/puc/
pucdata.c,v
retrieving revision 1.51.2.3
diff -u -r1.51.2.3 pucdata.c
--- pucdata.c 15 Dec 2006 22:31:37 - 1.51.2.3
+++ pucdata.c 6 May 2008 16:51:02 -
@@ -946,7 +946,7 @@
/* NetMos 4S0P PCI: 4S, 0P */
{ NetMos NM9845 Quad UART,
- { 0x9710, 0x9845, 0, 0x0014 },
+ { 0x9710, 0x9845, 0, 0x0004 },
{ 0x, 0x, 0, 0x },
{
{ PUC_PORT_TYPE_COM, 0x10, 0x00, COM_FREQ },
--
Marcel Moolenaar
[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: PCI serial card works on 6.2 but not on 6.3
On May 5, 2008, at 2:01 AM, Ingeborg Hellemo wrote: [EMAIL PROTECTED] said: Try loading the uart(4) driver, which can also replace sio(4) if I remember correctly. With puc(4) and sio(4) you have to make sure that both are either compiled into the kernel or loaded as a module. Do you know if this applies to uart(4) as well? Yes. It's a problem/quirk of the kernel module infrastructure, not of drivers. Note that it's save to compile-in puc(4) but have sio(4) or uart(4) loaded as a module. Not the other way around... -- Marcel Moolenaar [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: No more geom_gpt.ko ?
On Dec 28, 2007, at 9:58 AM, Greg Rivers wrote: The kernel module for GPT(8) partition tables is not present in RELENG_7 as it was in RELENG_6. Is options GEOM_PART_GPT now mandatory in the kernel config, or is not building the kernel module an oversight? Building modules is forthcoming. It will be in 7.1... -- Marcel Moolenaar [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: serial over /dev/ttyu0 does not work.
On May 19, 2007, at 8:26 AM, Stefan Lambrev wrote: I have disabled device sio in kernel and replaced it with device uart. And so dmesg |grep uart is : uart0: 16550 or compatible port 0x3f8-0x3ff irq 4 on acpi0 I was expecting to see uart1 too .. but it is not here. It's likely that the port doesn't exist or you disabled it in the BIOS. With ACPI you can be sure we won't try to create a device for hardware that isn't described by ACPI. I have: /dev/ttyu0 /dev/cuau0, also in /etc/ttys I have the following line: ttyu0 /usr/libexec/getty std.9600 vt100 on secure I have this configuration on other servers too and it works without problems, but the main difference that I found is when I use minicom. I think if I try to open /dev/cuau0 I should see Device busy - and on all other servers where I checked it does respond with Device busy as it is already used, but on this server I do not! Are you sure your minicom configuration is correct? Could it be that it still tries to open ttyd0? Also I notice that where the serial is NOT working I have this line in ps xa: 1653 ?? I 0:00.00 /usr/libexec/getty std.9600 ttyu0 In first moment I thought it is OK to have getty on ttyu0, but what is this ?? :) It means that there's no terminal associated with the getty process. It's perfectly normal. so I checked on the other server and I saw that there is NO getty on ttyu0 running at all (it is started when I start minicom from the other side of the serial but then it shows: 99615 u0 Ss+0:00.00 /usr/libexec/getty std.9600 ttyu0 and it is stopped when I stop minicom) Interesting. How is getty started exactly? BTW: In this case getty is associated with ttyu0 itself. That's not uncommon and happens when you manually start and/or stop getty. Any useful ideas where to look for ? Also switching back from uart to sio may sound OK, but it needs another restart :( The problem doesn't seem to be with uart(4). I see getty(8) and minicom(1) behaviour that's different on this box from other boxes (as per your description). It looks to me to be a config problem. -- Marcel Moolenaar [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: sio0: port may not be enabled
On Apr 21, 2007, at 1:07 AM, Stefan Lambrev wrote: Some systems apparently tie the serial port to ACPI functionality in a different way. For example, I have a couple boxes which have sio0 attached to acpi0 that work fine. In some other cases, I have ones which result in a non-working serial port unless I disable ACPI (thus sio0 shows up as being attached to isa0). Could you try uart(4) instead. It seems quite excessive to have to disable ACPI just to get a serial port working. I'd like to know if this is related to the sio(4) driver or something else. This did the trick: uart0: 16550 or compatible port 0x3f8-0x3ff irq 4 on acpi0 uart1: 16550 or compatible port 0x2f8-0x2ff irq 3 on acpi0 ports are swapped but this is probably because I swap them in bios, but this is ok. Serial is working and now I can start working on the main problem :) So it's not acpi problem, but instead problem with sio? So it appears. -- Marcel Moolenaar [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: sio0: port may not be enabled
On Apr 20, 2007, at 8:23 AM, Jeremy Chadwick wrote: Look closely at the dmesg line, note what device sio0 is claiming to be associated with (acpi0, not isa0): sio0: 16550A-compatible COM port port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 This is one of the drawbacks to using ACPI. This is not a drawback. It's partly why ACPI was designed and implemented: to describe legacy hardware. Some systems apparently tie the serial port to ACPI functionality in a different way. For example, I have a couple boxes which have sio0 attached to acpi0 that work fine. In some other cases, I have ones which result in a non-working serial port unless I disable ACPI (thus sio0 shows up as being attached to isa0). Could you try uart(4) instead. It seems quite excessive to have to disable ACPI just to get a serial port working. I'd like to know if this is related to the sio(4) driver or something else. Thanks, -- Marcel Moolenaar [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: sio0: port may not be enabled
On Apr 20, 2007, at 11:08 AM, Jeremy Chadwick wrote: On Fri, Apr 20, 2007 at 09:45:43AM -0700, Marcel Moolenaar wrote: On Apr 20, 2007, at 8:23 AM, Jeremy Chadwick wrote: Look closely at the dmesg line, note what device sio0 is claiming to be associated with (acpi0, not isa0): sio0: 16550A-compatible COM port port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 This is one of the drawbacks to using ACPI. This is not a drawback. It's partly why ACPI was designed and implemented: to describe legacy hardware. It's a drawback in the sense that if the technology is newer than what FreeBSD can handle/is made for, then administrators are forced to look at alternatives (other hardware or operating systems). I see what you mean. This may also be FreeBSD's drawback (i.e. the support for legacy systems). Some systems apparently tie the serial port to ACPI functionality in a different way. For example, I have a couple boxes which have sio0 attached to acpi0 that work fine. In some other cases, I have ones which result in a non-working serial port unless I disable ACPI (thus sio0 shows up as being attached to isa0). Could you try uart(4) instead. It seems quite excessive to have to disable ACPI just to get a serial port working. I'd like to know if this is related to the sio(4) driver or something else. Can you provide some directions explaining how to configure the kernel (other than device uart) and loader.conf or device.hints for appropriate variables? I'll be more than happy to try this out. Remove device sio from your kernel configuration. Also, make sure that if acpi is loaded as a module, everything that can attach to acpi is loaded as a module too (i.e. uart). I typically compile-in acpi. It's too fundamental for my tastes to not compile it into the kernel. Don't change your device.hints file. Hints are more likely to interfere than help out. With sio removed from the kernel, its hints won't harm. Don't add hints for uart. We're using acpi, so the hardware/firmware will tell us where serial ports are. There's no need for changes in loader.conf, unless you're using a serial console. In that case you need to tell uart where the console is. The following will put the console on COM1: set hw.uart.console=io:0x3f8 If you have a serial console, then you also want to make sure that you have a login prompt. Change /etc/ttys by replacing ttyd# into ttyu#. To have uart coexist with sio, uart has to create different device special files and you need to make sure that a getty is started for them in order to log in over the serial port. HTH, -- Marcel Moolenaar [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: 2.4TB disk - MBR and GPT coexist?
On Jan 13, 2007, at 12:03 AM, Jo Rhett wrote: On Jan 12, 2007, at 1:04 AM, Jo Rhett wrote: To make this into a step-by-step, what do you mean by restore the MBR partition ? From backup, or...? Marcel Moolenaar wrote: Manually recreate, I guess. When creating a GPT, the MBR is replaced by a PMBR. A PMBR is a MBR with a single partition spanning the whole disk (or as much as can be covered by the MBR) that has type 0xEE. The GPT kernel code expects such a partition but does not care if there are others. If you restore the MBR from a backup, the 0xEE partition will be gone and the GPT will not be used. It would probably be nice if gpt(8) could migrate without destroying the existing MBR partition, because restoring the MBR partition is the least intuitive step. Let me think about this for a bit... I am very interested in solving this problem, and have machines I am more than willing to dedicate to this project. I'm just somehow lacking a clear understanding of what I need to do to test this: 1. Install FreeBSD with a normal MBR partition and leftover free space 2. Migrate the partition to GPT (can I do this from CD fixit mode?) You should be able to do this on a running system provided you have kern.geom.debugflags=16 to allow writing to the disk when it has been mounted. Note that after this step the MBR is turned into a PMBR, so you need to restore the MBR before you do anything else otherwise you might find yourself with an unbootable machine. You should be able to use fdisk for this. After that you have both the MBR and GPT describing the same partition/slice and you should be able to reboot the machine. If you boot verbose, you should see that GPT claims the partitions. If not, stop. Use GPT to partition the free space on the disk. -- Marcel Moolenaar [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: 2.4TB disk - MBR and GPT coexist?
On Jan 12, 2007, at 1:04 AM, Jo Rhett wrote: Marcel Moolenaar wrote: On Jan 11, 2007, at 1:56 PM, Jo Rhett wrote: Since we're going to be stuck with old BIOSes for a long time after 2TB is a cheap disk drive at [store], is anyone considering doing the work to make GPT co-exist with an MBR block? It is already possible for them to coexist. It's not uncommon in the industry to use MBR partitions even though the disk has GPT. The point is that you need to tools to avoid making a mess. Ideally you want the MBR partitions mirrored by the GPT so that the kernel only has to deal with GPT. The BIOS will use the MBR to boot. The gpt(8) tool can actually be used to set this up. You partition the disk with fdisk, but only for the boot partition. Then you run gpt(8) to migrate the MBR into a GPT, specifying the -s option so that you get a single GPT partition overlapping the MBR slice. After that you restore the MBR partition. Now you can use GPT to define a big partition. The kernel will use GPT and since you used -s when you migrate the MBR, the kernel will create device nodes with the same name as it would for the MBR partitions... That is exactly what I was hoping to find, but was unable to be certain that it was possible from what I saw in the searches. To make this into a step-by-step, what do you mean by restore the MBR partition ? From backup, or...? Manually recreate, I guess. When creating a GPT, the MBR is replaced by a PMBR. A PMBR is a MBR with a single partition spanning the whole disk (or as much as can be covered by the MBR) that has type 0xEE. The GPT kernel code expects such a partition but does not care if there are others. If you restore the MBR from a backup, the 0xEE partition will be gone and the GPT will not be used. It would probably be nice if gpt(8) could migrate without destroying the existing MBR partition, because restoring the MBR partition is the least intuitive step. Let me think about this for a bit... -- Marcel Moolenaar [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: 2.4TB disk - MBR and GPT coexist?
On Jan 12, 2007, at 1:53 AM, Jason Thomson wrote: Marcel, do you know if it is possible to do this without destroying the existing file systems? In theory, yes. If you need or want to shuffle partitions or repartition, then it becomes a whole new game. Keeping existing partitions where they are is simpler and typically works. Be sure to try things out on a memory disk first. I haven't done any of this myself, so my reasoning is not backed by actual experience. -- Marcel Moolenaar [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: 2.4TB disk - MBR and GPT coexist?
On Jan 11, 2007, at 1:56 PM, Jo Rhett wrote: Since we're going to be stuck with old BIOSes for a long time after 2TB is a cheap disk drive at [store], is anyone considering doing the work to make GPT co-exist with an MBR block? It is already possible for them to coexist. It's not uncommon in the industry to use MBR partitions even though the disk has GPT. The point is that you need to tools to avoid making a mess. Ideally you want the MBR partitions mirrored by the GPT so that the kernel only has to deal with GPT. The BIOS will use the MBR to boot. The gpt(8) tool can actually be used to set this up. You partition the disk with fdisk, but only for the boot partition. Then you run gpt(8) to migrate the MBR into a GPT, specifying the -s option so that you get a single GPT partition overlapping the MBR slice. After that you restore the MBR partition. Now you can use GPT to define a big partition. The kernel will use GPT and since you used -s when you migrate the MBR, the kernel will create device nodes with the same name as it would for the MBR partitions... -- Marcel Moolenaar [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_6 tinderbox] failure on alpha/alpha
On Sep 2, 2006, at 9:33 PM, FreeBSD Tinderbox wrote: : cc -O2 -pipe -mcpu=ev4 -mtune=ev5 -mieee -Wall -DFREEBSD_ELF - DIN_RTLD -I/src/libexec/rtld-elf/alpha -I/src/libexec/rtld-elf -mno- fp-regs -fpic -DPIC -Wformat=2 -Wno-format-extra-args -Werror -c / src/libexec/rtld-elf/rtld.c /src/libexec/rtld-elf/rtld.c: In function `allocate_tls': /src/libexec/rtld-elf/rtld.c:2560: error: `TLS_TCB_SIZE' undeclared (first use in this function) /src/libexec/rtld-elf/rtld.c:2560: error: (Each undeclared identifier is reported only once /src/libexec/rtld-elf/rtld.c:2560: error: for each function it appears in.) /src/libexec/rtld-elf/rtld.c: In function `free_tls': /src/libexec/rtld-elf/rtld.c:2608: error: `TLS_TCB_SIZE' undeclared (first use in this function) *** Error code 1 Should be fixed now. Sorry about that... -- Marcel Moolenaar [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
ipfilter LOR-fest
(c381ca20,c3243a50,e90bfc40,c33e6c00,0) at sosend+0x593 kern_sendit(c3904c00,4,e90bfcbc,0,0) at kern_sendit+0x104 sendit(c3904c00,4,e90bfcbc,0,bfbfd47c) at sendit+0x161 sendto(c3904c00,e90bfd04,6,2,292) at sendto+0x4d syscall(2f,2f,2f,bfbfd47c,12750) at syscall+0x227 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (133, FreeBSD ELF32, sendto), eip = 0x2812a0ef, esp = 0xbfbfd41c, ebp = 0xbfbfd498 --- lock order reversal 1st 0xc06e25ec tcp (tcp) @ /nfs/freebsd/5.x/src/sys/netinet/tcp_input.c:619 2nd 0xc06a9ae0 ipf filter rwlock (ipf filter rwlock) @ /nfs/freebsd/5.x/src/sys/contrib/ipfilter/netinet/fil.c:1107 KDB: stack backtrace: kdb_backtrace(,c06bda88,c06bc3e0,c068caec,c06e0878) at kdb_backtrace+0x29 witness_checkorder(c06a9ae0,1,c0648afd,453,c06b5e1c,0,c065c663,6f) at witness_checkorder+0x49d _sx_slock(c06a9ae0,c0648afd,453,0,c364dc00) at _sx_slock+0x29 fr_check(c360d010,14,c3229000,1,e63daac8) at fr_check+0x430 fr_check_wrapper(0,e63daac8,c3229000,2,0) at fr_check_wrapper+0x2a pfil_run_hooks(c06e2180,e63dab3c,c3229000,2,0) at pfil_run_hooks+0xb3 ip_output(c364dc00,0,e63dab08,0,0,0) at ip_output+0x4de tcp_respond(0,c360d010,c360d024,c364dc00,0,87dab9ab,4) at tcp_respond+0x343 tcp_input(c364dc00,14,e25680d1,0,0) at tcp_input+0x2b65 ip_input(c364dc00) at ip_input+0x4f1 netisr_processqueue(c06e1818) at netisr_processqueue+0x6e swi_net(0) at swi_net+0x88 ithread_loop(c3095b00,e63dad38,c06b4c20,0,c0659fba) at ithread_loop+0x10c fork_exit(c04fd400,c3095b00,e63dad38) at fork_exit+0x66 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xe63dad6c, ebp = 0 --- -- Marcel Moolenaar USPA: A-39004 [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: How to use growfs on GPT
On Jan 8, 2005, at 7:54 PM, Emanuel Strobl wrote: The topic says all. I'd like to increase the size of the last GPT id (and there's space after the last sector of the last ID). Is it safe to delete it and create a new one with a bigger size? The gpt(8) utility does not destroy the partition contents. It is safe to destroy a partition and create a new one that's larger; from a partitioning point of view of course. -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED]
Re: 5.3: ed1: Ethernet address: aa:aa:aa:aa:aa:aa
On Dec 10, 2004, at 9:18 PM, Bruce Burden wrote: I build a 5.3 kernel and source from source. When I booted, I got: Copyright (c) 1992-2004 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 5.3-RELEASE-p2 #0: Fri Dec 10 22:48:56 GMT 2004 [EMAIL PROTECTED]:/home/obj/usr/src/sys/TIGERPROWL link_elf: symbol Debugger undefined KLD file acpi.ko - could not finalize loading You might want to resolve this first. I don't know what you load as modules, but what you're booting is inconsistent. This may apply to pccard or if_ed and possibly the root cause of your problems. Just a suggestion, -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mismatching vinum configurations
On Sun, Jul 20, 2003 at 08:27:00PM +0200, Joan Picanyol i Puig wrote: Hi, I had a power failure, and the on-disk configuration for vinum went bizarre. The logs read from disks are at http://biaix.org/pk/debug/ (log.$DEVICE files). The logs in da0 (barracuda) are the ones obviously wrong, I'm pretty sure the others are ok. Is this a 'virtually' dead drive? Can I force vinum to use the other's drive configuration? What's the less traumatic way to recover the data? I had the same problem twice. Also a power failure. There was no way I could fix it without trauma. I had to do the following (and I'm not joking about the reboots): WARNING: do not follow the steps below if you're not entirely sure what you're doing unless you already have nothing to lose... 1. Nuke the complete configuration, but make sure you know exactly what it was. 2. Reconfigure vinum from scratch in exactly the same way it was before. 3. Reboot the machine. I got kernel panics trying to recover my vinum volumes and that only made matters worse (it always can). 4a.For mirrored volumes you should be able to mark one drive as up, and mark the other(s) as empty (ie manually set the state). This forces a complete resync. Let it finish and reboot the machine afterwards. 4b.For RAID5 volumes you manually have to mark all disks as up and rebuild the parity. After that it's probably good to reboot the machine avoid kernel panics. Reboot twice if you're paranoid. Verify that the parity is ok! 5. fsck(8). 6. Drink lot's of alcoholic beverages to recover yourself after you verified you recovered vinum. 7. Reboot yourself. FYI, -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Bootstrapping issues with groff(1)
[I don't know why -current is CC'd this is clearly about -stable] Ruslan Ermilov wrote: Attached is the patch for RELENG_4. It works but I don't like how it pollutes the Makefile.inc1. Anyone with a better idea? Allow me to sidetrack for a moment: I just ugraded a machine from 4.1 to 4.2-stable without any problems. I'm a bit confused. Rene picks up RELENG_4 and sees his build fail. Why did it work for me? -- Marcel Moolenaar mail: [EMAIL PROTECTED] / [EMAIL PROTECTED] tel: (408) 447-4222 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Updating staroffice5 port for 4.1-RELEASE?
"Thomas R. Stromberg" wrote: Does someone plan on upgrading the StarOffice port to 5.2 before the 4.1-RELEASE? I think with all of the hype surrounding SO52 it might be a good idea to put it in ports, even if it installs pretty cleanly without it. The ports collection is already labeled, IIRC. -- Marcel Moolenaar mail: [EMAIL PROTECTED] / [EMAIL PROTECTED] tel: (408) 447-4222 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: how to update from FreeBSD 2.2.8 to RELENG_4
Andreas Klemm wrote: On Thu, Jul 13, 2000 at 10:53:18AM -0700, Marcel Moolenaar wrote: If you have the time, I hope you are willing to spend some time and effort to work on getting a 1-step upgrade working (or at least the buildworld part). Since I don't have a 2.2.8 machine, I can only do as much as support you... Let's see if I get a haddisk to play with. What procedure would you suggest ? Simply try such an update and see where it hangs ??? basicly, it's what I described in another mail that didn't go to -stable: checkout -stable sources on a 2.2.x machine (with x = 5 for now [to reply your other mail at the same time]) and do a buildworld. It will probably fail early. When you see a failure, identify it. If we have a fix, restart the build and watch it fail or complete. It might be a time-consuming task... If my backlog has been reduced, I'll probably try it under vmware myself. -- Marcel Moolenaar mail: [EMAIL PROTECTED] / [EMAIL PROTECTED] tel: (408) 447-4222 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: HEADS UP! Always use the 'make buildkernel' target to make yer kernels
Warner Losh wrote: In message [EMAIL PROTECTED] "Brandon D. Valentine" writes: : On Thu, 13 Jul 2000, Marcel Moolenaar wrote: : : Without an architecture prefix/postfix/directory somewhere in the path, : this prevents concurrent cross-builds. : It would be v.nice to have a src/sys/arch directory structure similiar : to NetBSD's since we actually have more than one architecture to : consider now. We'd already have: : src/sys/arch/i386 : src/sys/arch/pc98 : src/sys/arch/alpha : and work is under way to give us: : src/sys/arch/sparc : src/sys/arch/ppc : : If we're going to be restructuring src/sys anyway per the discussion : occuring on -current as of late, it might be product to make this change : as well and move our MD code into those directories. Don't forget arch/ia-32 and arch/ia-64. Then there's the arch/mips that I've done but which is so incomplete and bitrotted as to not be too useful to people. With 7 or 8 MD directories, an arch subdirectory is not too much to ask for. I can imagine that people wonder if and when we're going to reach that count and until then don't see the need to reorganize. With currently 3 MD directories and at least 3 coming up (including ia64), I'd say that now is probably the best time to introduce the subdirectory... My $0.02 -- Marcel Moolenaar mail: [EMAIL PROTECTED] / [EMAIL PROTECTED] tel: (408) 447-4222 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: make: don't know how to make dwarf1.c. Stop
Stone wrote: won't require steps 3 and 4/4a anymore and thus have a single pass source upgrade... By this do you mean having to reboot into single user mode to do a make installworld will become a thing of the past? No. I meant that you won't need to install a new kernel and reboot before you can do an installworld during upgrades. You don't really need to be in single user mode to do an installworld anyway. You might hit upon a conflict though, so it's not recommended... -- Marcel Moolenaar mail: [EMAIL PROTECTED] / [EMAIL PROTECTED] tel: (408) 447-4222 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: VIA chip set
On Tue, 4 Jul 2000, Chad R. Larson wrote: There might not be enough time for this, but: You still have 2 hours... Featured is a 700MHz AMD Athlon barebones system, including Boxed AMD K7 CPU mid tower ATX case with 300w power supply and, most important, an installed motherboard VIA KX133 chipset 1 AGP slot 5 PCI slots 1 ISA slot 56K modem 10/100 Ethernet Audio 3 DIMM slots for PC-133 memory One per customer, $399. Today only. Damn. I just bought this same configuration, only with a 750 Athlon friday... Can anyone report results with the Athlon and the KX133 chipset? Works great for me. I do see a kernel panic when I leave my Logitech joystick plugged in the USB port, but that's on 5-current. -- Marcel Moolenaar mail: [EMAIL PROTECTED] / [EMAIL PROTECTED] tel: (408) 447-4222 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: HELP PLEAS! with Oracle install!
Stan Brown wrote: I am trying to install Oralce on 4.0 STABEL. I have read teh Handbook section on this and done everythign it recomends. [snip] Now, whne I try to run the installer, I get an error message that says esentiallly that /usr/local/jre/bin/jre is not found. Now I think this must be tje Java Runtime Environment. Since I am runing in a Linux compatabilty shell. I belive the file it is really looking for is /compat/linux/usr/local/jre/bin/jre. The handbook describes Oracle 8.0.5.x. Oracle 8 doesn't have a Java installer. Oracle 8i does, but isn't covered by the handbook. The handbook does give a good starting point when trying to install and run Oracle 8i, but it is no following-these-easy-steps-to-guaranteed-success kind of description anymore (it never was :-) I suggest reading the Oracle installation manual before you attempt to do anything unsupported with it. And with anything unsupported: assume you don't get any support :-) I have istalled the jre jdk, and linux-jdk ports, all to no vail. The Oracle manual clearly stated that blackdown JDK was recommended. That may have changed in the mean time of course, but I don't think that it will be as trivial as installing just any JDK port (and specifically a FreeBSD port). Could someone _PLESE_ explain what I am doing wrong? 1. You're installing the wrong Oracle version, or you're reading the wrong description for the Oracle version you're trying to install. 2. You're pioneering with the expectation that the road ahead is already paved. -- Marcel Moolenaar mail: [EMAIL PROTECTED] / [EMAIL PROTECTED] tel: (408) 447-4222 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: upgrading from 3.4-S to 4.0-S no longer works
Glen Foster wrote: Yes, I know the update wasn't supposed to have worked forever and I'm not complaining. I just thought this might save someone the hour or so it takes to find out the hard way. I don't see a reason why we gratuitously break source updating. If there are definite grounds for breaking source updating, then so be it. Otherwise we should maintain it... -- Marcel Moolenaar mail: [EMAIL PROTECTED] / [EMAIL PROTECTED] tel: (408) 447-4222 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
