Re: [CURRENT] install: link /usr/share/man/man4/ntb_hw.4.gz -> /usr/share/man/man4/nve.4.gz: No such file or directory
On 04/30/13 02:24, O. Hartmann wrote: > When doing a > > make installworld > > on FreeBSD 10.0-CURRENT #1 r250041: Mon Apr 29 09:34:03 CEST 2013 amd64 > > (sources at "At revision 250097") > > I receive this sticky error below: > > /usr/share/man/man4/nve.4.gz -> /usr/share/man/man4/ntb_hw.4.gz > install: link /usr/share/man/man4/ntb_hw.4.gz > -> /usr/share/man/man4/nve.4.gz: No such file or directory > *** [_maninstall] Error code 71 > > Stop in /usr/src/share/man/man4. > *** [realinstall] Error code 1 > > > regards, > > Oliver > > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" Yeah. I screwed up. It is fixed in r250110 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: SAN disk with freebsd?
Hi Aaron, On Sun, 2003-08-10 at 10:10, Aaron Wohl wrote: > Anyone using a storage area network with freebsd (or linux)? Anything to > recommend as working well or to stay way from? I've had FreeBSD 4.6-RELEASE with a QLA2200 card connected to an IBM ESS (Shark) through IBM 2109-S16 switches (Brocade 3800) working very well. You have to tell the Shark to only use 1 interface for that host (we have 3 per Shark) as there is no dual pathing code yet for FreeBSD. Carl. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Upgrading from 5.0-RELEASE to -CURRENT on sparc64
On Wed, Feb 12, 2003 at 02:46:21PM -0500, Andrew R. Reiter wrote: > I have a u60 (mp) and installed 5.0-RELEASE with the miniinst iso. I am > trying to buildworld, but am receiving: [snip] > > ... I did not script(1) this so I dont have a further backtrace (so to > speak). I can produce one if requested. > > Anyone have any thoughts? Or am I being a fool linking /usr/obj -> > /work/obj and building world in /work/arrwrk/src/ ? I had the same problem but on x86. My solution was to manually re- build world. I started out by building the libraries and then running a make includes after moving the old /usr/include out of the way. Then I built everything in gnu from the top level (/usr/src/gnu). I installed it all of course and then I ran a buildworld and it was fine afterwards. I can offer no explanation as to what was broken though: I didn't care at the time - I only cared about making it work. -- Carl Schmidt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make.conf and make.conf(5)
On Wed, Nov 20, 2002 at 03:37:32PM -0500, Tom Rhodes wrote: > On Wed, 20 Nov 2002 10:10:14 -0500 > Carl Schmidt <[EMAIL PROTECTED]> wrote: > > > On Wed, Nov 20, 2002 at 09:53:35AM -0500, Tom Rhodes wrote: > > > On Wed, 20 Nov 2002 12:09:14 +0200 > > > Sheldon Hearn <[EMAIL PROTECTED]> wrote: > > > > On (2002/11/19 15:17), Carl Schmidt wrote: > > > > > > > > > The following PR has two patches attached which address the lack > > > > > of some documentation of make.conf in the manual page. It also > > > > > contains a patch for make.conf to fix style inconsistencies and > > > > > two(if I recall correctly) items which are documented in the > > > > > manual page but did not exist in the example conf. > > > > > > > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=45470 > > > > > > > > I see that Tom Rhodes has taken this one. > > > > > > > > Tom, I like this patch. When you commit it, please tidy up the > > > > new description for MAKE_SHELL, which I think is a bit more chatty > > > > than necessary. :-) > > > > > > > > Thanks, Carl. This work is always a pain in the butt to do, but > > > > readers of the manpage get very frustrated if it isn't done. > > > > > > > > Ciao, > > > > Sheldon. > > > > > > > > > > Not a problem, Sheldon. I'm going to clean up a tad bit of the > > > markup, unless Carl wants to hear my comments ;) > > > > > > I should get this done quickly. > > > > What markup are you referring to so I know in the future what not to > > do?-- > > Carl Schmidt > > > > For one, the '/' should be marked up as: > > .Pa / . > > and a hard sentence break exists (a hard sentence break is when we > don't start a new line for the new sentence) although its trivial > work. Would you like a copy of the completed patch? Nah I think I see what you mean. Thank you. -- Carl Schmidt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make.conf and make.conf(5)
On Wed, Nov 20, 2002 at 09:53:35AM -0500, Tom Rhodes wrote: > On Wed, 20 Nov 2002 12:09:14 +0200 > Sheldon Hearn <[EMAIL PROTECTED]> wrote: > > On (2002/11/19 15:17), Carl Schmidt wrote: > > > > > The following PR has two patches attached which address the lack of > > > some documentation of make.conf in the manual page. It also > > > contains a patch for make.conf to fix style inconsistencies and two > > > (if I recall correctly) items which are documented in the manual > > > page but did not exist in the example conf. > > > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=45470 > > > > I see that Tom Rhodes has taken this one. > > > > Tom, I like this patch. When you commit it, please tidy up the > > new description for MAKE_SHELL, which I think is a bit more chatty > > than necessary. :-) > > > > Thanks, Carl. This work is always a pain in the butt to do, but > > readers of the manpage get very frustrated if it isn't done. > > > > Ciao, > > Sheldon. > > > > Not a problem, Sheldon. I'm going to clean up a tad bit of the > markup, unless Carl wants to hear my comments ;) > > I should get this done quickly. What markup are you referring to so I know in the future what not to do? -- Carl Schmidt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
make.conf and make.conf(5)
The following PR has two patches attached which address the lack of some documentation of make.conf in the manual page. It also contains a patch for make.conf to fix style inconsistencies and two (if I recall correctly) items which are documented in the manual page but did not exist in the example conf. http://www.freebsd.org/cgi/query-pr.cgi?pr=45470 http://docs.freebsd.org/cgi/getmsg.cgi?fetch=116926+0+current/freebsd-doc -- Carl Schmidt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Latest fetch on current broken
On Sun, Oct 27, 2002 at 10:38:36PM -0500, Craig Rodrigues wrote:
> On Sun, Oct 27, 2002 at 10:21:02PM -0500, Craig Rodrigues wrote:
> > On Sun, Oct 27, 2002 at 06:31:27PM -0800, Manfred Antar wrote:
> > > I noticed it when doing a portupgrade cdrtools
> > > So yes anything that uses fetch is not going to work
> >
> > OK, I started tracing this down.
> >
> > Here's how to get debugging versions:
> > cd /usr/src/lib/libfetch
> > make clean
> > make DEBUG_FLAGS=-g
> > make DEBUG_FLAGS=-g install
> >
> > cd /usr/src/usr.bin/fetch
> > make clean
> > make DEBUG_FLAGS=-g NOSHARED=yes
> > make DEBUG_FLAGS=-g NOSHARED=yes install
>
>
> I tracked this down further to the _fetch_writev() function
> in libfetch/common.c. Try this patch:
>
> --- lib/libfetch/common.c.origSun Oct 27 22:38:16 2002
> +++ lib/libfetch/common.c Sun Oct 27 22:40:12 2002
> @@ -525,7 +525,7 @@
> return (-1);
> }
> total += wlen;
> - while (iovcnt > 0 && wlen > iov->iov_len) {
> + while (iovcnt > 0 && wlen >= iov->iov_len) {
> wlen -= iov->iov_len;
> iov++;
> iovcnt--;
Yay, this works for me. :)
--
Carl Schmidt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: Old port recompiles needed (Re: Unknown symbol "__sF")
On Mon, Oct 14, 2002 at 12:45:41PM +0900, Makoto Matsushita wrote: > carl> 3.4 hours is a lot of time on a dial-up connection (granted it > carl> is not a one size fits all period of time). > > You forget that you still compressed image with about 30 hours (at > least, full 1 day or more), and it is not helpful for ordinal users, > not you. I fail to see how a reduction of hours (even just one) is insignificant to someone on a dial-up connection. Time is money for some people; even a meager three hours. > Again, reducing hours/percentages with compressed image doesn't > matter; please focus total download time which is actually needed for > all users. Missing the point is not helpful for the discussion. Again, I fail to see how a reduction in download time for -anyone- is insignificant. Can you explain how I am missing the point? I think it would be better to focus on whether or not the snapshot machine can even handle such a task, and, more importantly, whether the administrator even wants to do it. I e-mailed [EMAIL PROTECTED] about the task. If that is you I hope you'll forward your response to the freebsd-current list. -- Carl Schmidt [Random Quote] Be careful of reading health books, you might die of a misprint. -- Mark Twain To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: Old port recompiles needed (Re: Unknown symbol "__sF")
On Sun, Oct 13, 2002 at 10:40:20PM -0500, David W. Chapman Jr. wrote: > On Sun, Oct 13, 2002 at 11:29:32PM -0400, Carl Schmidt wrote: > > On Mon, Oct 14, 2002 at 11:43:20AM +0900, Makoto Matsushita wrote: > > > tlambert2> That's 3.4 hours saved on a 28.8K modem download time, > > > tlambert2> overall... a 14% reduction in size. > > > > > > The percentage doesn't matter. If ISO image is compressed, user who > > > downloads the image may de-compress that image to burn (I don't know > > > any about the burner softwares which support compressed ISO image). > > > What's happen if there is no space to make de-compressed image on a HDD? > > > > I do not follow this. If the user can not fit a non-compressed image > > on their drive then they certainly will not be downloading a non- > > compressed image nor a compressed image hence rendering this whole > > discussion moot for that user...it seems so to me at least. Maybe I am > > not seeing something? > > The temporary space required to do the decompression is what I am > assuming is being reference, although I'm not sure how accurate that > argument is. I did a little test to see how that works. If you gzip a file and gunzip it and follow the sizes of each file it seems that the file being de-compressed decreases in size while the new file increases in size. I think it is safe to say that gzip does not require temporary space, except an extra inode for de-compression. I could be wrong though. > > Whether we think the size is too large for dial-up or not people will > > still download it. And 200MB is absolutely nothing compared to what > > people put up with for full-size distribution ISOs. You could argue > > that not everyone has gzip (I would assume primarily a Windows user). > > As far as I know there is a DOS version of gzip. This would be where > > you might need both types of images (compressed and not compressed), > > and that is something up to the snapshots people. > > Winzip supports tar and gz, winrar supports bzip2 > > > One might argue that Mr. Lambert is simply speculating that anyone has > > a 28.8k connection anymore. What are the odds that everyone fits this: > > > > a: they live close enough to a provider to get broadband (see 'b'), > > I did not think distance was a requirement for cable modem, but I do > agree with your logic that not everyone has broadband. The distance argument is probably not relevant. I remember a long time ago some person from the UK complaining about having to use ISDN because NTL did not provide cable at that distance, or something. I honestly do not know about that. >From Qwest: <<
Re: HEADS UP: Old port recompiles needed (Re: Unknown symbol "__sF")
On Mon, Oct 14, 2002 at 11:43:20AM +0900, Makoto Matsushita wrote: > tlambert2> That's 3.4 hours saved on a 28.8K modem download time, > tlambert2> overall... a 14% reduction in size. > > The percentage doesn't matter. If ISO image is compressed, user who > downloads the image may de-compress that image to burn (I don't know > any about the burner softwares which support compressed ISO image). > What's happen if there is no space to make de-compressed image on a HDD? I do not follow this. If the user can not fit a non-compressed image on their drive then they certainly will not be downloading a non- compressed image nor a compressed image hence rendering this whole discussion moot for that user...it seems so to me at least. Maybe I am not seeing something? 3.4 hours is a lot of time on a dial-up connection (granted it is not a one size fits all period of time). > Also, the image size is still over 200MB; it is too large to fetch via > 28.8k link IMHO (saving 3.4hours doesn't help either). There are lots > of broadband connection services we can temporary buy (at airport, > starbucks, etc), so why not use it for large file downloads :-) I disagree with the first sentence; see my reply above. I simply disagree that 3.4 hours is not helpful. Whether we think the size is too large for dial-up or not people will still download it. And 200MB is absolutely nothing compared to what people put up with for full-size distribution ISOs. You could argue that not everyone has gzip (I would assume primarily a Windows user). As far as I know there is a DOS version of gzip. This would be where you might need both types of images (compressed and not compressed), and that is something up to the snapshots people. One might argue that Mr. Lambert is simply speculating that anyone has a 28.8k connection anymore. What are the odds that everyone fits this: a: they live close enough to a provider to get broadband (see 'b'), b: they can afford broadband, c: they live close enough to a Starbucks and/or airport, and d: is going to put out that kind of effort to do a-c when they can just as well hope that the snapshot server(s) have the space and power to compress an image so that they can stay in the comfort of their home with their 28.8k Internet connection? I think more than maybe is accounted for. I liken it to simply forgetting about the "others"...sort of like for a long time the blind, deaf, et cetera were left out of most people's thoughts when it came to accessibility (whether that is with computers or physical access to something). I think the FTP installation should be just fine for people with a dial-up connection if they really really really want to have -CURRENT. I've used it a few times for getting snapshots with no harm done. If the snapshot server(s) are not up to task then all of this is useless discussion. Someone ``in the know'' should simply get up and say "hey, our servers can not handle this; end of story" instead of speculating. No one has said that yet that I am aware of. As you might be able to tell I have no idea who actually runs the snapshot server(s) nor am I aware of how many, if there are more than one, there are. Sorry. Of course that's all just my opinion; I could be wrong. -- Carl Schmidt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
New panic fun.
Decided to update my source tree today. Evidently this was not a bright
move. I built my kernel and whatnot, powered off (rebooting on my
laptop doesn't work...), and startx'ed. Then I ran mozilla.
poof
Fatal trap 9: general protection fault while in kernel mode
instruction pointer = 0x8:0xc028db0f
stack pointer = 0x10:0xd1e1c9e4
frame pointer = 0x10:0xd1e1c9e4
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= resume, IOPL = 0
current process = 665 (mozilla-bin)
Uptime: 4m53s
Dumping 255 MB
ata0: resetting devices ..
done
[CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to
abort] [CTRL-C to abort] 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240
---
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:223
223 dumping++;
(kgdb) where
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:223
#1 0xc0190a75 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:355
#2 0xc0190c4c in poweroff_wait (junk=0xc0298468, howto=-773732132)
at /usr/src/sys/kern/kern_shutdown.c:508
#3 0xc012343d in db_panic () at /usr/src/sys/ddb/db_command.c:450
#4 0xc01233e0 in db_command (last_cmdp=0xc02ca100, cmd_table=0xc0298468,
aux_cmd_tablep=0x104, aux_cmd_tablep_end=0xc26775b0)
at /usr/src/sys/ddb/db_command.c:346
#5 0xc01234ab in db_command_loop () at /usr/src/sys/ddb/db_command.c:472
#6 0xc012599a in db_trap (type=9, code=0) at /usr/src/sys/ddb/db_trap.c:72
#7 0xc027a982 in kdb_trap (type=9, code=0, regs=0xd1e1c9a4)
at /usr/src/sys/i386/i386/db_interface.c:166
#8 0xc0289358 in trap_fatal (frame=0xd1e1c9a4, eva=0)
at /usr/src/sys/i386/i386/trap.c:841
#9 0xc0288ebc in trap (frame=
{tf_fs = 24, tf_es = 16, tf_ds = -1078001648, tf_edi = -773731000, tf_esi =
-1033407056, tf_ebp = -773731868, tf_isp = -773731888, tf_ebx = 514, tf_edx =
-1033407056, tf_ecx = -773731696, tf_eax = -773731696, tf_trapno = 9, tf_err = 0,
tf_eip = -1071064305, tf_cs = 8, tf_eflags = 65538, tf_esp = -773731852, tf_ss =
-1071064388}) at /usr/src/sys/i386/i386/trap.c:643
#10 0xc027bd98 in calltrap () at {standard input}:98
#11 0xc028dabc in npxsetregs (td=0x0, addr=0x0)
at /usr/src/sys/i386/isa/npx.c:1000
#12 0xc028349d in set_fpcontext (td=0xc26775b0, mcp=0x0)
at /usr/src/sys/i386/i386/machdep.c:2230
#13 0xc0281ea0 in sigreturn (td=0xc26775b0, uap=0x0)
at /usr/src/sys/i386/i386/machdep.c:757
#14 0xc0289636 in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 0, tf_esi = 135491152, tf_ebp =
-1077942724, tf_isp = -773730956, tf_ebx = 677337812, tf_edx = 677337244, tf_ecx =
-1077942616, tf_eax = 344, tf_trapno = 22, tf_err = 2, tf_eip = 677510491, tf_cs = 31,
tf_eflags = 662, tf_esp = -1077942768, tf_ss = 47})
at /usr/src/sys/i386/i386/trap.c:1050
#15 0xc027bded in Xint0x80_syscall () at {standard input}:140
---Can't read userspace from dump, or kernel process---
And there you have it. I cannot begin to fathom what caused this. So far
it seems that only running mozilla causes it to occur.
I can supply more information if needed of course.
--
Carl Schmidt
[Random Quote]
Satellite Safety Tip #14:
If you see a bright streak in the sky coming at you, duck.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: My problems with GEOM
On Sun, Oct 06, 2002 at 08:26:03PM -0400, Robert Watson wrote: > On Sun, 6 Oct 2002, Carl Schmidt wrote: > > > > Mounting root from ufs:/dev/ad0s1a > > > > > > and hangs -- only a physical reset works. However, breaking into the > > > debugger, and running a trace, I get (hand-copied): > > Hmm. I actually ran into this problem on some diskless booting boxes, but > it went away so I assumed it was a local nit since I was messing with VFS > substantially on the boxes in question. Apparently not. (This was a > month or two ago, and quite pre-GEOM as default). > > Here's my first suggestion: the root file system is mounted by the init > process--your trace shows the stack of the current interrupt thread for > keyboard I/O, since that's the foreground thread when you break to the > debugger. Try using 'trace 1' to trace init instead; also, if you could > provide the output from the ddb ps command, that would be very useful. > BTW, you really want to be using a serial console for this sort of thing > -- copying stuff out by hand is (a) a pain, and (b) very error prone :-). I believe you were addressing the originator of this thread but I will go ahead and show my trace/ps: db> trace 1 mi_switch(c0f014e0,cd33dca8,1,80202,c0f018f0) at mi_switch+0x1b3 ithread_schedule(c25e6b00,1) at ithread_schedule+0x10d sched_ithd(1) at sched_ithd+0x37 Xintr1() at Xintr1+0x67 --- interrupt, eip = 0xc025b5b0, esp = 0xcd33dcfc, ebp = 0xcd33dd04 --- cpu_unpend(cd33dd14,c018478d,cd33d3c,c019a750,2800) at cpu_unpend+0x28 cpu_critical_exit(cd33dd3c,c019a750,2800,1,73e) at cpu_critical_exit+0x12 critical_exit(2800,1,73e,0,c0f05c40) at critical_exit+0x21 ast(cd33dd48) at ast+0x39c doreti_ast() at doreti_ast+0x1a db> ps 33 c25dd528 cddbf000000 204 norm[SLPQ psleep c02dc580][SLP] bufdaemon 9 c25dd6e0 cddc000 20c norm[RUNQ] pagezero 8 c25dd898 cddc1000000 204 norm[SLPQ psleep c02df91c][SLP] vmdaemon 7 c25dda50 cddc2000000 204 norm[SLPQ psleep c02c9b18][SLP] pagedaemon 6 c25ddc08 cddc3000000 204 norm[SLPQ g_down c02b1a58][SLP] g_down 5 c25dddc0 cddc4000000 204 norm[SLPQg_up c02b1a54][SLP] g_up 4 c2615000 d1ddf000000 204 norm[SLPQ g_events c02b1a4c][SLP] g_event 32 c26151b8 d1de000 204 new [IWAIT] irq8: rtc 31 c2615370 d1de1000000 204 new [IWAIT] irq0: clk 30 c2615528 d1de2000000 204 norm[IWAIT] irq6: fdc0 29 c26156e0 d1de3000000 204 new [IWAIT] irq3: sio1 28 c2615898 d1de4000000 204 new [IWAIT] irq4: sio0 27 c0f071b8 cd395000000 204 new [IWAIT] swi0: tty:sio 26 c0f07370 cd396000000 204 new [IWAIT] irq12: psm0 25 c0f07528 cd397000000 204 norm[CPU 0] irq1: atkbd0 24 c0f076e0 cd398000000 204 norm[RUNQ] irq5: pcm0 23 c0f07898 cd399000000 204 norm[IWAIT] irq15: ata1 22 c0f07a50 cd39a000000 204 norm[IWAIT] irq14: ata0 3 c0f07c08 cd39b000000 204 norm[CVQ cbb cv c25e074c][SLP] cbb1 2 c0f07dc0 cd39c000000 204 norm[CVQ cbb cv c25e014c][SLP] cbb0 21 c25dd000 cdd7e000000 204 new [IWAIT] irq11: cbb0 cbb1+ 20 c25dd1b8 cdd84000000 204 norm[SLPQ nothing c042473c][SLP] acpi_thermal 19 c25dd370 cdd85000000 204 norm[IWAIT] irq9: acpi0 18 c0f0 cd319000000 204 new [IWAIT] irq13: 17 c0f001b8 cd38c000000 204 new [IWAIT] swi5: task queue 16 c0f00370 cd38d000000 204 norm[IWAIT] swi5: acpitaskq 15 c0f00528 cd38e000000 204 norm[SLPQ sleep c03e1aa0][SLP] random 14 c0f006e0 cd38f000000 204 new [IWAIT] swi1: net 13 c0f00898 cd39000 204 new [IWAIT] swi4: vm 12 c0f00a50 cd391000000 20c norm[IWAIT] swi6: tty:sio clock 11 c0f00c08 cd392000000 20c norm[Can run] idle 1 c0f00dc0 cd393000000 0004200 norm[RUNQ] init 10 c0f07000 cd394000000 204 norm[CVQ ktrace c02d7c44][SLP] ktrace 0 c02b2780 c0453000000 200 norm[SLPQ sched c02b2780][SLP] swapper -- Carl Schmidt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: My problems with GEOM
On Sun, Oct 06, 2002 at 05:08:00PM -0600, Seth Hieronymus wrote:
> Hello,
>
> After recompiling a kernel after the GEOM transition, my boot gets as
> far as:
>
> Initializing GEOMetry subsystem
> ad0: 28629MB [58168/16/63] at ata0-master UDMA33
> acd0: CDROM at ata1-master PIO4
> afd0: 239MB [239/64/32] at ata1-slave PIO3
> Mounting root from ufs:/dev/ad0s1a
>
> and hangs -- only a physical reset works. However, breaking into the
> debugger, and running a trace, I get (hand-copied):
>
> Debugger("manual escape to debugger")
> Stopped at Debugger+0x54: xchgl %ebx,in_Debugger.0
> db> trace
> Debugger(c0331a32,4,1,0,1) at Debugger+0x54
> scgetc(c03cc1e0,2,c031a8f5,2fd,c1876b40) at scgetc+0x445
> sckbdevent(c03a6ee0,0,c03cc1e0,c034b1c0,8) at sckbdevent+0x1d0
> atkbd_intr(c03a6ee0,0,c8793d0c,c01a25c2,c03a6ee0) at atkbd_intr+0x2c
> atkbd_isa_intr(c03a6ee0,0,c0317bac,215,c0bbf370) at atkbd_isa_intr+0x21
> ithread_loop(c185fe00,c8793d48,c031790b,34d,7641000a) at
> ithread_loop+0x182
> fork_exit(c01a2440,c185fe00,c8793d48) at fork_exit+0xa5
> fork_trampoline() at fork_trampoline+0x1a
> --- trap 0x1, eip = 0, esp = 0xc8793d7c, ebp = 0 ---
>
> Am I doing something wrong here? Thanks for any help. My pre-GEOM
> dmesg, and kernel config follow. A kernel and world from the day before
> the GEOM switch works fine.
I also have the aforementioned problem. I had this problem several
months before GEOM was enabled so I can not vouch for it being GEOM-
related. Any time I trace after this apparent hang I get a mostly
identical trace as you have shown. I have no idea why it happens. I
only know that it happens only with FreeBSD on my laptop. No other
operating system I have tried on it has this problem. Unfortunately I
cannot be more verbose (that I am aware of) than the trace. I have
been unsuccessful at forcing a core dump, and I do not know why.
I am at the point where if someone offers an idea to get more
information I could possily be more useful. I will try adding printf's
where I think would be useful but this is a needle in a haystack issue
for me since I am not 100% aware of the internals.
--
Carl Schmidt
[Random Quote]
Be different: conform.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
GEOM
ons UFS_DIRHASH options COMPAT_43 options COMPAT_FREEBSD4 options KTRACE options SYSVSHM options SYSVMSG options SYSVSEM options P1003_1B options _KPOSIX_PRIORITY_SCHEDULING options KBD_INSTALL_CDEV options INCLUDE_CONFIG_FILE options DDB options ATA_STATIC_ID options RANDOM_IP_ID options TCP_DROP_SYNFIN options ZERO_COPY_SOCKETS options PSM_HOOKRESUME options PSM_RESETAFTERSUSPEND options SC_ALT_MOUSE_IMAGE options SC_HISTORY_SIZE=512 options SC_PIXEL_MODE options SC_KERNEL_CONS_ATTR="(FG_GREEN|BG_BLACK)" options SC_TWOBUTTON_MOUSE options GEOM device isa device eisa device pci device fdc device ata device atadisk device atapicd device atkbdc device atkbd device psm device vga device splash device sc device npx device pmtimer device cbb device pccard device cardbus device sio device loop device ether device pty device bpf -- Carl Schmidt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: A different light, perhaps.
On Mon, Sep 23, 2002 at 09:43:59PM -0700, Kris Kennaway wrote: > Yes, I expect the problem will be resolved by those who have already > said they'll resolve it ;) Okay good. I obviously missed a lot of the discussion on this. While we're at it someone should close PR 43317 since I am a fucking idiot and don't know what is going on. Bleh. -- Carl Schmidt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: A different light, perhaps.
On Tue, Sep 24, 2002 at 12:37:24AM -0400, Carl Schmidt wrote: > On Mon, Sep 23, 2002 at 09:34:07PM -0700, Kris Kennaway wrote: > > On Tue, Sep 24, 2002 at 12:10:23AM -0400, Carl Schmidt wrote: [...] > Right, okay. But NetBSD's sort actually works. I should rephrase this ... NetBSD's sort works with the current world setup. -- Carl Schmidt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: A different light, perhaps.
On Mon, Sep 23, 2002 at 09:34:07PM -0700, Kris Kennaway wrote: > On Tue, Sep 24, 2002 at 12:10:23AM -0400, Carl Schmidt wrote: > > > Get rid of gnu-sort from contrib and use NetBSD's sort, which was > > imported five months ago but apparently never incorporated into the > > build process. > > It was, briefly, but was backed out because it's not a sufficiently > complete replacement for everyone's liking. > > > Gnu-sort does not appear to understand +# arguments whereas NetBSD's > > sort does. > > It's actually a case of NetBSD's sort not disabling non-standard > behaviour when you ask it to. Right, okay. But NetBSD's sort actually works. -- Carl Schmidt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: A different light, perhaps.
On Mon, Sep 23, 2002 at 08:28:06PM -0700, walt wrote: > Carl Schmidt wrote: > > After running cvsup at about 5PM > > EDT (September 23, 2002 -- using cvsup3) and running a full build I am > > happy to report that everything worked fine... > > In an attempt to understand this black magic we practice every day > could I ask you to do two quick experiments for me? Heh... > 1. Type 'sort +1' at any command prompt. What do you see? > > 2. cd /usr/src/lib/libncurses > make clean && make > What do you see? >[Warning: this may break your world on the next go-round.] Okay I ran into the same problems everyone else ran into and I have a solution. Get rid of gnu-sort from contrib and use NetBSD's sort, which was imported five months ago but apparently never incorporated into the build process. Gnu-sort does not appear to understand +# arguments whereas NetBSD's sort does. This solved the problem for me. -- Carl Schmidt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
A different light, perhaps.
There seems to be many complaints of things being broken. Maybe I'm just lucky and never cvsup when things are broken. I have encountered -no- errors over the past month when building world and kernel. So anyway to add to that I'd just like to report on today's build so as to balance things out. After running cvsup at about 5PM EDT (September 23, 2002 -- using cvsup3) and running a full build I am happy to report that everything worked fine. No war stories to speak of. laptop% uname -a FreeBSD laptop.slackerbsd.org 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Mon Sep 23 19:20:39 EDT 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/LAPTOP i386 Now if only my laptop would stop overheating whenever I run FreeBSD on it. That is all. -- Carl Schmidt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: GEOM code ready for testing
Hi, On Mon, 2002-03-11 at 06:34, Poul-Henning Kamp wrote: > The GEOM code is now ready for early testing: Would GEOM support accessing a device via multiple paths? (ie could we write a method that would do that?) My current situation is that I have a couple of IBM ESS F20 Sharks each with 3 fibre channel cards hooked to 3 brocade switches. When I allocate a LUN out of either shark it appears as 3 separate devices. IBM ship software called "SDD" that provides a single virtual device "VPATH" on NT, Solaris and AIX and load balances. At the moment when I hook up a FreeBSD box I just select one of the devices and ignore the others. Mildly annoying and I have to bring down the FreeBSD boxes when we upgrade the microcode on the shark. Carl. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: netstat -f inet broken ?
On Mon, Dec 24, 2001 at 02:01:19PM +0100, Wilko Bulte wrote: > On Mon, Dec 24, 2001 at 02:02:00PM +0100, Martin Blapp wrote: > > > > Hi All, > > > > As we just have noted, there is no output anymore for > > netstat -f inet. Has the support been dropped ? > > I also don't get any output. carbon> netstat -f inet Active Internet connections Proto Recv-Q Send-Q Local Address Foreign Address(state) tcp4 0 0 Carbon.6667*.*LISTEN tcp4 0 0 Carbon.http*.*LISTEN tcp4 0 0 Carbon.smtp*.*LISTEN tcp4 0 0 Carbon.ssh *.*LISTEN Etc. Works fine. FreeBSD carbon.slackerbsd.org 4.5-PRERELEASE FreeBSD 4.5-PRERELEASE #0: Mon Dec 24 03:29:03 EST 2001 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/CARBON i386 -- Carl Schmidt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: netstat -f inet broken ?
On Mon, Dec 24, 2001 at 02:02:00PM +0100, Martin Blapp wrote: > Hi All, > > As we just have noted, there is no output anymore for > netstat -f inet. Has the support been dropped ? Incorrect. > Also there are only unix domain sockets in the normal > netstat output. I cannot see any tpc4 connections anymore. We'll get to that. > I noted this in 4.5 PRERELEASE too. It used to work in > 4.3 RELEASE and 4.4 RELEASE. It still works. > > So it got broken trough a MFC between 4.4 and 4.5. No. > I think this is important for security reasons ! I don't because there is no issue. You need to rebuild your userland because of changes to the network code. That's all. -- Carl Schmidt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Support for large mfs
Hi Matthew, On Thu, 27 Apr 2000, Matthew Dillon wrote: > I can't imagine why MFS would perform better... it shouldn't, every > block is stored in system memory *TWICE* (once in the VM cache, and > once in the mfs process's address space). If you have enough system I've been running a MFS /tmp dir since around 2.2.4, are you now saying that it would be better (under 4.0-STABLE or CURRENT) to run a swap backed vnode fs? Carl. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Dual Pathing to SCSI/FC devices.
On Wed, 29 Mar 2000, Brad Knowles wrote: > At 4:28 PM -0800 2000/3/28, Matthew Jacob wrote: > > Yes, we very much has considered this. What's your issue about this, per se? > Myself, I just need to be able to tell the system that SCSI ID x > LUN y is actually the same logical device as SCSI ID v LUN w, but > that one is preferred and the other is backup, and have FreeBSD deal > with doing the re-targeting in the CAM SCSI driver. heh, the buzzword for this is "Dynamic Failover". :) In management circles where the current focus is on 24x7, this is seen as a distinct advantage. > The end result should be that nothing above the CAM SCSI driver > should know that a switch has occurred -- especially not programs > Same deal with fibrechannel as SCSI. > Does that about sum it up? Yes. That was pretty much what I was thinking. "Dual Pathing" the buzzword for using both paths to the device would also be desirable, but then you get into things like wanting to optimise data paths depending on how busy each path is. > Oh, and Carl -- I don't suppose you're looking at Hitachi DF400 > (sometimes rebadged as Comparex D1400) units, are you? If so, I'd No, sorry. I can't actually say what box we're buying yet since we haven't signed the contract. :( Carl. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Dual Pathing to SCSI/FC devices.
On Tue, 28 Mar 2000, Matthew Jacob wrote: > Umm, okay. Is this with Veritas DMP or VCS? Good question. DMP I think. I'm not sure what VCS is. > an active-active configuration. If you use Greg Lehey's VINUM in FreeBSD, I'm > not clear about what it's role in terms of recognizing redundant paths might There doesn't seem much point in using VINUM with an external RAID5 box (although we use VINUM a lot on other machines). > identification restrictions that could cause an upset. The CAM midlayer does > track Vital Product Data (like drive serial numbers), but this is put together > with a bus address (e.g, HBA, bus on HBA, target, lun) to track whether > particular device has changed at that location or not- not whether that > particular spindle is replicated elsewhere. Would it be hard to add intelligence to this layer that would detect if a drive (via it's VPD info) is visible on multiple busses? If so is there a point in CAM where it could be modified to handle, at the minimum, a redundant path or better yet, use multiple paths to a device? The box to which I'm hooking this up has sufficient performance to handle 16 U2W SCSI links running hard. Being able to utilise multiple paths could be a big performance win. > Absolutely. I mean, we do have a supported Fibre Channel card (Qlogic 2100 and > Qlogic 2200), but not as much testing as one would like. I have a Qlogic 2200 on order to test this out. > You should note that there isn't, for fibre channel, any particular address > wiring enforced except by that which the target device does (e.g., if the Would this be similar to the situation that we had with FreeBSD before you could wire down devices? > Let me know if this is enough info to help. I'm getting a little beyond my depth in CAM internals here. But it is *very* interesting. :) Thanks, Carl. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Dual Pathing to SCSI/FC devices.
Hi Matthew, On Tue, 28 Mar 2000, Matthew Jacob wrote: > Yes, we very much has considered this. What's your issue about this, per se? Well, the driver for asking was my management asking if FreeBSD supported this, as we're going to do it on AIX (with the Dual Pathing Option) and with Solaris (running Veritas which I need to investigate more). We're reasonably big on redundancy here and we're running a number of critical systems on FreeBSD (DNS, WINS, DHCP, primary webserver, PDF server, etc). > Right now there's no framework code to directly exploit or prohibit multiple > paths to the same disk, whether via Fibre Channel or SCSI. Ok, but I suspect it would get a trifle upset if I started duplicating LUNS. :) I really don't know how much work this would be but would be interested in helping. I'm not a kernel hacker but I can offer testing resources (well, in about a month or so when the box arrives) for SCSI and possibly Fibre Channel if someone has code. Carl. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Dual Pathing to SCSI/FC devices.
Is anyone working on/considering this? I'm about to start hooking FreeBSD boxes up to a *big* disk array which has the ability to make LUNS appear on multiple interfaces. Being able to access LUNS via multiple paths could be a reasonable performance gain, as well as enhancing reliability. Carl. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
No Subject
subscribe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Mandating USA_RESIDENT
On Tue, 18 Jan 2000, Kris Kennaway wrote: > Fetching packages due to network topology is another idea I've wanted to > implement for a while, although I was thinking of doing it dynamically by > testing the available bandwidth to each of the hosts (and storing it in a > database) and using them in order of increasing bandwidth. You also need to cater for those of us behind restrictive firewalls that keep our own copies of the packages distribution. Carl. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 3.4 -> current upgrade/bootstrap problem
Hi David, On Mon, 17 Jan 2000, David O'Brien wrote: > On Mon, Jan 17, 2000 at 12:39:12PM +1100, Carl Makin wrote: > > Here is what I did... > > 1. install gcc 2.95 port. > > 2. cd /usr/bin and rename cc and gcc to *.old and symlink cc and gcc to > > /usr/local/bin/gcc295 (Remember to delete the .old entries once you're > > finished) > This is definately the wrong thing to be doing. I don't guarentee that > the GCC 2.95 port can properly build world or kernels on 3.4. Anyway, > the upgrade should be self-hosting, and this approach isn't. Yes, I thought it wasn't ideal either but gcc 2.7.2.1 that comes with 3.4-RELEASE doesn't seem to be able to build the world OR the kernel at the moment. At least with the above steps I got the system up enough to be able to rebuild world and the kernel with the 4.0 toolset. I also had problems with "genassym". I had to build and install it before I could compile the kernel. Carl. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 3.4 -> current upgrade/bootstrap problem
On Sun, 16 Jan 2000, David W. Chapman Jr. wrote: > The procedure for going form 3.4 to -current is > > make your -current kernel > reboot > do make world > make -current kernel again I have just successfully done this. I had problems trying to compile with gcc 2.7.2 so I installed the gcc 2.95 package and did all my compiles using it. Here is what I did... 1. install gcc 2.95 port. 2. cd /usr/bin and rename cc and gcc to *.old and symlink cc and gcc to /usr/local/bin/gcc295 (Remember to delete the .old entries once you're finished) I did the cc/gcc rename as the buildworld kept complaining that it couldn't find gcc295. :( Then I built the 4.0-CURRENT config so I could build a kernel. 2. update to current sources (cd /usr ; cvs co src) 3. cd /usr/src/usr.sbin/config 4. "make ; make install" Created and built the new kernel. 5. cd /usr/src/sys/i386/conf 6. create new kernel config file 7. config -r KERNEL 8. cd /usr/src/sys/compile/KERNEL 9. "make depend ; make ; make install" Then booted into the kernel to do the rest of the install. 10. reboot into single user mode (boot -s) 11. mount / /usr /var /tmp (readwrite) 12. cd /usr/src 13. "make buildworld" (I think at this point I had problems using the "-j14" parm) 14. "make installworld" 15. cd /etc 16. run "mergemaster" and update your configuration 17. reboot into 4.0-CURRENT Then I rebuilt the kernel with a complete 4.0-CURRENT toolset. 18. cd /usr/src/sys/i386/conf 19. "config -r KERNEL" 20. cd /usr/src/sys/compile/KERNEL 21. "make depend ; make ; make install" 22. reboot This was done on a Dell PowerEdge 2300 with Dual PIII 450s, 512Mb RAM and 54Gb disk (3 x 9Gb in a Vinum stripe). Carl. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
