Re: Checksum offload support for Intel 82550/82551
> Hello,
>
> > Yes, it's me. I'm still alive.
> It's great to hear that one of the most talented FreeBSD hackers is back
> in business :)
>
> Does this means that you can afford some time to investigate the problems
> regarding your old software?
Not unless it's something I can fix using easily available resources.
I can't easily drop everything and slap together a test setup with
exactly the right software and hardware I need to debug everyone's
particular problem. ("This bug only occurs in -CURRENT as of 30
seconds ago and on an UltraSPARC 10 with 16 if_dc interfaces and
I need you to fix it _NOW_ pleasepleasepleaseI'llevengiveyouahandjob.")
> I mean ng_fec primarily, because I couldn't get help in the past few
> months/years(?)...
>
> You may know, or not it is now part of FreeBSD, the only problem is that
> it does not work.
I'm shocked. Shocked, I tell you.
> I filed a PR (kern/46720) about a month ago, but haven't gotten too much
> response back. On these lists I think there is a consensus (search the
> archives :) that the FEC implementation is a good thing.
This particular PR relates to using ng_fec with BPF (i.e. tcpdump fec0
blows up). The code has evidently rotted quite a bit since it was imported.
I just fixed it.
> Another problem, which I faced years ago that if you want to use .1q
> tagged packets on a FEC interface, it just does not works.
I don't know if this is still a problem or not. At the moment, I have
no easy way to test it.
> There are more verbose details on these lists too.
> Are there any chances to get these fixed?
Like I said, it depends on time and availability of resources.
-Bill
--
=
-Bill Paul(510) 749-2329 | Senior Engineer, Master of Unix-Fu
[EMAIL PROTECTED] | Wind River Systems
=
"If stupidity were a handicap, you'd have the best parking spot."
=
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: "NTLDR missing" after 5-RELEASE install
Matt Smith wrote: What does your Drive Layout look like? Is your W2k partition FAT32? Has it always been the first partition on the drive, or did you move it, using something like partition magic? Is freeBSD in the extended partition? -Matt On Tue, 2003-02-25 at 11:58, Andrew Boothman wrote: Quoting Lucas Holt <[EMAIL PROTECTED]>: It probably is. You need to put in the win 2k CD and do a repair on your windows install.. unfortunetely this may screw up your freebsd install. On Tuesday, February 25, 2003, at 05:58 AM, Andrew Boothman wrote: Hi! I've just installed 5-RELEASE, and I asked for the FreeBSD Boot Manager to be installed on both my HDDs. When the machine boots I'm given options for : F1 - DOS F5 - Drive 2 Hitting F5 takes me to a second menu, where I can boot FreeBSD no problem. My problem is that Win2k will no longer boot Hitting F1 displays a message that, "NTLDR is missing". I've tried all the repair options on the Win2k setup disc to no avail I think. I'm sorry this isn't directly FreeBSD related, but I really hope my Win2k installation isn't hosed. Thanks for replying! I can't understand how the 5.x boot manager has managed to break my windows boot, i've never had any trouble under 3.x or 4.x, both of which played with windows perfectly nicely. I think i've tried all of the various repair options on the Win2k CD, including getting it to do a fresh installation into a different folder (c:\tempwin), but even that failed with the "NTLDR missing" message! However you no longer get the booteasy (F1 F2) menu anymore, so Windows must have rewritten something. It still doesn't explain why Win2k still won't boot. My experience with the FBSD boot manager is virtually zero, so I can't address it's workings, but I use GRUB as a booter just because it gets me out of so many jams like yours -- if something isn't where you thought it was you can point GRUB at your disks and let it do the looking for you. The secret is to make a boot floppy with GRUB installed on it. Once you have that there's no machine that's unbootable, and you can reinstall GRUB in seconds if it gets overwritten by Bill & Co. For example, IIRC, I just went thru this myself (although it's all so routine now I can't even remember what I do to bail out anymore) when I installed XP on a brand new disk and then installed FBSD afterwards. I got the MBR screwed up just like you, then ran the XP install disk in "Repair" mode which got XP to boot again but overwrote the FBSD booter. So all I did was boot my trusty GRUB floppy and reinstalled GRUB on the MBR in about 60 seconds and -- done. The next evil news is that I've never really gotten FBSD's incarnation of GRUB to work right for me, so I just install in on the floppy from a linux machine and use that for the FBSD machine. If you have access to GRUB and need instructions I'd be happy to help. Just let me know. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: patch for the nVidia driver and -CURRENT
Apparently, On Tue, Feb 25, 2003 at 10:49:16PM +0100,
Maxime Henrion said words to the effect of;
> Morten Rodal wrote:
> > On Tue, Feb 25, 2003 at 07:28:09PM +0100, Maxime Henrion wrote:
> > [snip a lot of the patch]
> > > @@ -1431,7 +1442,8 @@
> > > SLIST_FOREACH(at, &sc->alloc_list, list) {
> > > if (offset >= at->address &&
> > > offset < at->address + at->size)
> > > -return atop(vtophys(offset));
> > > +*paddr = vtophys(offset);
> > > +return 0;
> > > }
> > >
> > > return -1;
> >
> > Should the function return 0 even if the if (offset..) fails? I have
> > no clue about the nvidia kernel driver (or kernel stuff at all) but it
> > seems to me that the only way the function can return -1 is if the
> > list is empty.
>
> And this is consistant with what the code was doing before. This change
> is not a functional change, it's just a necessary update due to API
> changes.
I think he's referring to missing braces around the if which was changed
from 1 statement to 2.
Jake
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: patch for the nVidia driver and -CURRENT
On Tue, 2003-02-25 at 23:45, Patrick Hartling wrote: > Does anyone have this working with GDM 2.4.1.3 on -current? I've found > that I can use the nvidia driver with Maxime's patch on a freshly built > -current system as long as I don't use GDM. If I start up GDM, the > system freezes as soon as the nvidia logo is replaced by the GDM login > screen. In the end, it doesn't make any difference to me if I use GDM > or XDM, but I would like to know if there is some existing problem with > the accelerated nvidia driver and GDM or if my local X configuration is > somehow broken. Thanks. I run gdm2 on -stable with the nVidia driver, and it does work. So if there's a problem, it's either with the driver on -CURRENT or in your gdm config. Try copying /usr/X11R6/etc/gdm/factory-gdm.conf over /usr/X11R6/etc/gdm.conf, and see if your problem persists. Joe -- PGP Key : http://www.marcuscom.com/pgp.asc signature.asc Description: This is a digitally signed message part
Re: Errors with wireless
* De: Sam Leffler <[EMAIL PROTECTED]> [ Data: 2003-02-25 ] [ Subjecte: Re: Errors with wireless ] > > * De: Sam Leffler <[EMAIL PROTECTED]> [ Data: 2003-02-25 ] > > [ Subjecte: Re: Errors with wireless ] > > > > wi0: tx failed, retry limit exceeded > > > > > > If this happens again show the output of sysctl hw.wi. > > > > I get those constantly when doing e.g. an interactive FTP session. > > > > ([EMAIL PROTECTED]:~)10% sysctl hw.wi > > hw.wi.txerate: -1 > > hw.wi.debug: 0 > > > > Should I be tuning txerate or something? > > I blew it. The default setting of -1 was supposed to disable all tx error > messages (a la the old driver) but instead caused all messages to be printed > (no rate limiting). It looks like you need to do something like: > > sysctl hw.wi.txerate=99 > > to disable the error messages or set it to some other value N to get no more > than N messages/second printed. I'll fix the code to set the default to a > large number. Making it 2^31-1 seems to have no effect. My kernel is about 14 days old, maybe it was debörken in that time? Feb 25 22:40:32 luna sudo: jmallett : TTY=ttyp7 ; PWD=/usr/people/jmallett ; USER=root ; COMMAND=/sbin/sysctl hw.wi.txerate=2147483647 Feb 26 04:41:58 luna kernel: wi0: tx failed, retry limit exceeded Feb 26 04:42:13 luna last message repeated 9 times ([EMAIL PROTECTED]:~)18% sysctl hw.wi.txerate hw.wi.txerate: 2147483647 Soo... I tried your value: Feb 25 22:44:49 luna sudo: jmallett : TTY=ttyp7 ; PWD=/usr/people/jmallett ; USER=root ; COMMAND=/sbin/sysctl hw.wi.txerate=99 Feb 26 04:45:00 luna kernel: wi0: tx failed, retry limit exceeded And then that's that. I'm confused? Thanx, juli. -- Juli Mallett <[EMAIL PROTECTED]> - AIM: BSDFlata -- IRC: juli on EFnet OpenDarwin, Mono, FreeBSD Developer - ircd-hybrid Developer, EFnet addict FreeBSD on MIPS-Anything on FreeBSD - Never trust an ELF, COFF or Mach-O! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: patch for the nVidia driver and -CURRENT
Does anyone have this working with GDM 2.4.1.3 on -current? I've found that I can use the nvidia driver with Maxime's patch on a freshly built -current system as long as I don't use GDM. If I start up GDM, the system freezes as soon as the nvidia logo is replaced by the GDM login screen. In the end, it doesn't make any difference to me if I use GDM or XDM, but I would like to know if there is some existing problem with the accelerated nvidia driver and GDM or if my local X configuration is somehow broken. Thanks. -Patrick walt wrote: Maxime Henrion wrote: --X1bOJ3K7DJ5YkBrT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi all, Recent interface changes made the nVidia driver unbuildable on -CURRENT. The attached patch should make it work as it used to. Please let me know if it doesn't. Yes! [Big kiss to Maxime] Thank you! The only thing I needed to do to make it work was to delete this line from nv-freebsd.h: #error This driver does not support FreeBSD 5.0/-CURRENT! As long as you are patching you may as well patch that one also, yes? [patch snipped] -- Patrick L. Hartling | Research Assistant, VRAC [EMAIL PROTECTED] | 2274 Howe Hall Room 2624 PGP: http://www.137.org/patrick/pgp.txt | T: +1.515.294.4916 http://www.137.org/patrick/ | http://www.vrac.iastate.edu/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Errors with wireless
Ditto. Constantly get those errors. smak# ls -lad dmesg.today -rw--- 1 root wheel 32121 Feb 25 03:02 dmesg.today All tx failed messages. Same sysctl values as well. James. - Original Message - From: "Juli Mallett" <[EMAIL PROTECTED]> To: "Sam Leffler" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Tuesday, February 25, 2003 8:34 PM Subject: Re: Errors with wireless > * De: Sam Leffler <[EMAIL PROTECTED]> [ Data: 2003-02-25 ] > [ Subjecte: Re: Errors with wireless ] > > > wi0: tx failed, retry limit exceeded > > > > If this happens again show the output of sysctl hw.wi. > > I get those constantly when doing e.g. an interactive FTP session. > > ([EMAIL PROTECTED]:~)10% sysctl hw.wi > hw.wi.txerate: -1 > hw.wi.debug: 0 > > Should I be tuning txerate or something? > -- > Juli Mallett <[EMAIL PROTECTED]> - AIM: BSDFlata -- IRC: juli on EFnet > OpenDarwin, Mono, FreeBSD Developer - ircd-hybrid Developer, EFnet addict > FreeBSD on MIPS-Anything on FreeBSD - Never trust an ELF, COFF or Mach-O! > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Errors with wireless
> * De: Sam Leffler <[EMAIL PROTECTED]> [ Data: 2003-02-25 ] > [ Subjecte: Re: Errors with wireless ] > > > wi0: tx failed, retry limit exceeded > > > > If this happens again show the output of sysctl hw.wi. > > I get those constantly when doing e.g. an interactive FTP session. > > ([EMAIL PROTECTED]:~)10% sysctl hw.wi > hw.wi.txerate: -1 > hw.wi.debug: 0 > > Should I be tuning txerate or something? I blew it. The default setting of -1 was supposed to disable all tx error messages (a la the old driver) but instead caused all messages to be printed (no rate limiting). It looks like you need to do something like: sysctl hw.wi.txerate=99 to disable the error messages or set it to some other value N to get no more than N messages/second printed. I'll fix the code to set the default to a large number. Sam To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Errors with wireless
* De: Sam Leffler <[EMAIL PROTECTED]> [ Data: 2003-02-25 ] [ Subjecte: Re: Errors with wireless ] > > wi0: tx failed, retry limit exceeded > > If this happens again show the output of sysctl hw.wi. I get those constantly when doing e.g. an interactive FTP session. ([EMAIL PROTECTED]:~)10% sysctl hw.wi hw.wi.txerate: -1 hw.wi.debug: 0 Should I be tuning txerate or something? -- Juli Mallett <[EMAIL PROTECTED]> - AIM: BSDFlata -- IRC: juli on EFnet OpenDarwin, Mono, FreeBSD Developer - ircd-hybrid Developer, EFnet addict FreeBSD on MIPS-Anything on FreeBSD - Never trust an ELF, COFF or Mach-O! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Errors with wireless
> I'm getting a LOT of these. > > ether_input: drop bdg packet, bif 0x5 This was a stray debugging printf I forgot to remove. Update your system. > wi0: tx failed, retry limit exceeded If this happens again show the output of sysctl hw.wi. Sam To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Ethernet (xl) will not transmit or receive
Kevin wrote: > I updated my 5.0 system built in late January to RELENG_5_0 on Sunday > and the Ethernet was not working. I tried again last night with no > change in behavior. > > The system is an AMD K6-2 on an ASUS P5A mobo. I have a 3Com 3c905B > Ethernet which had been working fine on a kernel built in late > January. > > The dmesg is not too meaningful, but the system shows no errors. It > simply never receives a packet. ARPs are all incomplete and no packets > are transmitted although netstat -in indicates that they are. The > packets never actually reach the wire, though. > > I can't believe that no one else has this card, but I didn't find > anything in the archives on it. I experienced the exact same behavior with my GF's GigaByte GA-5AN AMD K6-2 motherboard. Both a 3COM and a Realtek (yeah, I know...) card refused to pass packets, staying in hardware loopback. The link light on both cards would remain on until it appears the device was probed. At that point the link was lost permanently. The motherboard and both cards work fine with FreeBSD 4.7, which I even re-tested after the futile 5.0-RELEASE installation. I even flashed in the latest BIOS, but that had no effect. (The hardware has since been re-tasked and is no longer available for testing). --Lucky Green To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Errors with wireless
I'm getting a LOT of these. ether_input: drop bdg packet, bif 0x5 wi0: tx failed, retry limit exceeded Running a recent -current. FreeBSD 5.0-CURRENT #0: Sat Feb 15 13:12:32 PST 2003 Just seems to be an annoyance. Everything seems to work just fine. James. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: "NTLDR missing" after 5-RELEASE install
Hi!
I also encountered the same problem and I thought it was my own mistake.
Attempt to repair the partition failed. Even new installation was
failed. I did fdisk /mbr after booting through diskette into dos and
then installing fresh windows 2000 also failed. The copy process from cd
to hd is okay but when the pc is rebooted to continue installation,
nothing happened. It won't boot and there are no messages displayed.
My hd layout: first 4G partition was fat32. windows 2000 was on the
second partition (6G ntfs) and the last 10G partition was my freebsd 5
release.
I've reformatted my hd now and using windows 2000 with freebsd 5 release
on another machine.
Thanks.
On Wed, 2003-02-26 at 00:58, Andrew Boothman wrote:
> Quoting Lucas Holt <[EMAIL PROTECTED]>:
>
> > It probably is. You need to put in the win 2k CD and do a repair on
> > your windows install.. unfortunetely this may screw up your freebsd
> > install.
> >
> > On Tuesday, February 25, 2003, at 05:58 AM, Andrew Boothman wrote:
> >
> > > Hi!
> > >
> > > I've just installed 5-RELEASE, and I asked for the FreeBSD Boot
> > > Manager to be installed on both my HDDs.
> > >
> > > When the machine boots I'm given options for :
> > >
> > > F1 - DOS
> > > F5 - Drive 2
> > >
> > > Hitting F5 takes me to a second menu, where I can boot FreeBSD no
> > > problem. My problem is that Win2k will no longer boot Hitting F1
> > > displays a message that, "NTLDR is missing". I've tried all the repair
> >
> > > options on the Win2k setup disc to no avail I think.
> > >
> > > I'm sorry this isn't directly FreeBSD related, but I really hope my
> > > Win2k installation isn't hosed.
>
> Thanks for replying!
>
> I can't understand how the 5.x boot manager has managed to break my windows
> boot, i've never had any trouble under 3.x or 4.x, both of which played with
> windows perfectly nicely.
>
> I think i've tried all of the various repair options on the Win2k CD, including
> getting it to do a fresh installation into a different folder (c:\tempwin), but
> even that failed with the "NTLDR missing" message! However you no longer get
> the booteasy (F1 F2) menu anymore, so Windows must have rewritten
> something. It still doesn't explain why Win2k still won't boot.
>
> I'm running out of ideas and I *really* don't want to have to reformat my
> windows drive!
>
> Other than this (fairly major) problem, my 5.0 installation went really well,
> even ACPI seems to be working perfectly and I even found a KLD to support my on-
> board sound card! :)
>
> I really want to get windows booting again so I can continue to play with 5.0
> without worrying...
>
> Any help is much appricated!
>
> Thanks!
>
> Andrew
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
--
Nawfal bin Mohmad Rouyan.
System Engineer,
Multimedia University.
main(i){(10-putchar(((25208>>3*(i+=3))&7)+(i?i-4?100:65:10)))?main(i-4):i;}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
rpcbind DoS when running with -l
Hi, I've just run into a new bug. I was running rpcbind with the -l flag, and when I started Opera and it tried connecting to 127.0.0.1:111 to begin the DNS resolution phase, rpcbind started fork()'ing and eating up all resources. After a few minutes, I could get this from `ps`: root ~ # ps ax PID TT STAT TIME COMMAND 0 ?? ZW 0:00.00 (rpcbind) 0 ?? ZW 0:00.00 (rpcbind) 0 ?? ZW 0:00.00 (rpcbind) 0 ?? ZW 0:00.00 (rpcbind) 0 ?? ZW 0:00.00 (rpcbind) [snip] 11259 ?? S 0:00.03 rpcbind: logit (rpcbind) 11260 ?? S 0:00.03 rpcbind: logit (rpcbind) 11262 ?? S 0:00.03 rpcbind: logit (rpcbind) 11263 ?? S 0:00.02 rpcbind: logit (rpcbind) 11264 ?? S 0:00.02 rpcbind: logit (rpcbind) [snip] and the box wouldn't respond until I finally got X killed and thus Opera too. Fred -- "The purpose of Physics 7A is to make the engineers realize that they're not perfect, and to make the rest of the people realize that they're not engineers." pgp0.pgp Description: PGP signature
Re: SB Live goes silent after pcm commit
On Tue, Feb 25, 2003 at 11:13:23PM +0100, ?yvind Rakv?g wrote:
> I believe the commit Feb 20 17:31:11 2003 UTC on
> src/sys/dev/sound/pci/emu10k1.c broke something.
>
> With a kernel built from 17:00 sources sound works, from 19:00 there is
> only the sound of silence. Everything looks OK, xmms, mpg123 etc play,
> but no sound.
>
> The pcm driver is compiled into the kernel, i haven't tested loading as
> module.
>
> dmesg|grep pcm:
> pcm0: port 0x9400-0x941f irq 5 at device 13.0 on pci0
> pcm0:
>
> Soundcard: Soundblaster Live 1024! Player
> Motherboard: Asus A7V133, Via Apollo KT133A chipset
>
> Soundcard is sharing irq with an Intel NIC and the onboard USB
> controller.
Hi,
Could you please try the attached patch (to be applied in
/sys/dev/sound/pci).
Thanks,
Olivier
Index: emu10k1.c
===
RCS file: /home/ncvs/src/sys/dev/sound/pci/emu10k1.c,v
retrieving revision 1.32
diff -u -p -r1.32 emu10k1.c
--- emu10k1.c 23 Feb 2003 01:06:58 - 1.32
+++ emu10k1.c 26 Feb 2003 00:43:54 -
@@ -1022,9 +1022,9 @@ emu_intr(void *p)
static void
emu_setmap(void *arg, bus_dma_segment_t *segs, int nseg, int error)
{
- void **phys = arg;
+ bus_addr_t *phys = arg;
- *phys = error? 0 : (void *)segs->ds_addr;
+ *phys = error? 0 : (bus_addr_t)segs->ds_addr;
if (bootverbose) {
printf("emu: setmap (%lx, %lx), nseg=%d, error=%d\n",
@@ -1043,7 +1043,7 @@ emu_malloc(struct sc_info *sc, u_int32_t
if (bus_dmamem_alloc(sc->parent_dmat, &buf, BUS_DMA_NOWAIT, &map))
return NULL;
if (bus_dmamap_load(sc->parent_dmat, map, buf, sz, emu_setmap, addr, 0)
- || !addr)
+ || !*addr)
return NULL;
return buf;
}
@@ -1094,7 +1094,7 @@ emu_memalloc(struct sc_info *sc, u_int32
ofs = 0;
for (idx = start; idx < start + blksz; idx++) {
mem->bmap[idx >> 3] |= 1 << (idx & 7);
- tmp = (u_int32_t)(u_long)((u_int8_t *)&blk->buf_addr + ofs);
+ tmp = (u_int32_t)(u_long)((u_int8_t *)blk->buf_addr + ofs);
/* printf("pte[%d] -> %x phys, %x virt\n", idx, tmp, ((u_int32_t)buf)
+ ofs); */
mem->ptb_pages[idx] = (tmp << 1) | idx;
ofs += EMUPAGESIZE;
SB Live goes silent after pcm commit
I believe the commit Feb 20 17:31:11 2003 UTC on src/sys/dev/sound/pci/emu10k1.c broke something. With a kernel built from 17:00 sources sound works, from 19:00 there is only the sound of silence. Everything looks OK, xmms, mpg123 etc play, but no sound. The pcm driver is compiled into the kernel, i haven't tested loading as module. dmesg|grep pcm: pcm0: port 0x9400-0x941f irq 5 at device 13.0 on pci0 pcm0: Soundcard: Soundblaster Live 1024! Player Motherboard: Asus A7V133, Via Apollo KT133A chipset Soundcard is sharing irq with an Intel NIC and the onboard USB controller. signature.asc Description: This is a digitally signed message part
Re: "NTLDR missing" after 5-RELEASE install
Andrew Boothman writes: > [...] > I didn't really change much about my system when I installed FreeBSD. > > Windows is installed on the whole of the first HDD, and FreeBSD on the whole of > the second. Prior to installing 5.0, the second disc had an old installation of > 4.6 that I wasn't using. > > When installing, I asked sysinstall to install booteasy on the first drive, but > otherwise leave it unchanged. I removed the existing slice on the second drive > and got sysinstall to create a new slice filling the drive, I then allowed > sysinstall to auto-size the partitions and complete the installation. > > I've tried every repair option that I can find on the Win2k CD. I've tried > the "fixboot" and "fixmbr" commands in the recovery console many times, and > despite fixmbr complaining about an "unusual" mbr every time, installing a new > one apparently makes no difference. I eventually managed to remove booteasy > from the first drive so that "NTLDR is missing" appears straight away, but that > is hardly a victory. I even followed Microsoft's instructions in knowledgebase > article 318728 and performed a brand new installation of windows into > c:\tempwin but even this new installation failed to boot with the same problem. > Therefore it would seem that whatever the problem is, Win2k's setup prog either > can't fix it or is oblivious to it. It's looking more and more like I'm going > to have to reformat this drive as I seem to have no way of getting Win2k > operating again, but I'd _really_ like to understand what happened here, not > least to ensure I don't repeat the same problems when I come to try and dual- > boot again! > > Apologies for this getting increasingly off-topic, but I can't understand what > I've done wrong here as I've done this many times before with 4.x. > > As ever, any light-shedding would be much appricated :) I had several problems installing 5.0 release onto my sandbox machine, and the solution might be relevant. My sandbox machine had a single disk, uses a "stock" (what came on the drive) master boot record, and had several primary partitions (aka slices). The first partition/slice contained a windows2000 install, the second partition had a linux installation w/ the GRUB boot loader installed in the beginning of the partition. The linux parition is marked active (using Partition Magic from windows), so the normal boot sequence goes: MBR --> GRUB ---+--> Linux | +--> Windows depending on the choice made in grub. I boot this way because the sandbox machine is a test environment for my laptop, and suspend to disk stuff doesn't seem to work on the laptop unless the vendor's MBR is in place. My intent was to add Freebsd to the third partition. I ran through the install and told the installer to just leave the MBR alone. Among the things that I discovered were: - both the linux partition *AND* the newly installed FreeBSD partition ended up marked active. - There was a problem with data somewhere in the BIOS/DOS partition table concerning CHS values and LBA values for various parts of the partition. (might have the acronym's wrong). Both of these rendered the machine unable to boot, I recovered it once by booting from a floppy, getting into windows, and running partition magic, and on a separate test run by booting from a live linux cd and playing with various fdisk-oid programs available there. So, all that said, maybe your partition table is slightly scrod, not so badly that it won't get through the MBR but badly enough that it can't find the NT partition? It'd be interesting to see what parition magic had to say about it. g. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: cc: Internal error: Illegal instruction (program as)
"Paul A. Howes" wrote: > > All; > > These two kernel options seem to have solved the problem. Builds now > run smoothly and error-free. I read the comments in NOTES about these > options and something clicked: I recall that most Pentium processors > will only deal with 4 kB pages. Aren't 4 MB pages a feature of the Xeon > processor, as it can address much more memory? > 4Mb pages were introduced in Intel Pentium along with other V86 mode extensions, to increase Translation Lookaside Buffer (TLB) hit rate. 36-bit address path was implemented in Pentium Pro to access 64Gb address range, though CPU could work in 32-bit mode, too; ASZ[1:0]# signals were used in order to specify address bus width. I suppose P4 behaves somewhat similar, though its bus interface is totally different to GTL\AGTL used in PPro to PIII systems. --- Regards, Rhett __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: "NTLDR missing" after 5-RELEASE install
Quoting Matt Smith <[EMAIL PROTECTED]>: > What does your Drive Layout look like? Is your W2k partition FAT32? > Has it always been the first partition on the drive, or did you move > it, > using something like partition magic? Is freeBSD in the extended > partition? > -Matt > On Tue, 2003-02-25 at 11:58, Andrew Boothman wrote: > > Quoting Lucas Holt <[EMAIL PROTECTED]>: > > > > > It probably is. You need to put in the win 2k CD and do a repair on > > > > your windows install.. unfortunetely this may screw up your freebsd > > > > install. > > > > > > On Tuesday, February 25, 2003, at 05:58 AM, Andrew Boothman wrote: > > > > > > > Hi! > > > > > > > > I've just installed 5-RELEASE, and I asked for the FreeBSD Boot > > > > Manager to be installed on both my HDDs. > > > > > > > > When the machine boots I'm given options for : > > > > > > > > F1 - DOS > > > > F5 - Drive 2 > > > > > > > > Hitting F5 takes me to a second menu, where I can boot FreeBSD no > > > > > problem. My problem is that Win2k will no longer boot Hitting > F1 > > > > displays a message that, "NTLDR is missing". I've tried all the > repair > > > > > > > options on the Win2k setup disc to no avail I think. > > > > > > > > I'm sorry this isn't directly FreeBSD related, but I really hope > my > > > > Win2k installation isn't hosed. I didn't really change much about my system when I installed FreeBSD. Windows is installed on the whole of the first HDD, and FreeBSD on the whole of the second. Prior to installing 5.0, the second disc had an old installation of 4.6 that I wasn't using. When installing, I asked sysinstall to install booteasy on the first drive, but otherwise leave it unchanged. I removed the existing slice on the second drive and got sysinstall to create a new slice filling the drive, I then allowed sysinstall to auto-size the partitions and complete the installation. I've tried every repair option that I can find on the Win2k CD. I've tried the "fixboot" and "fixmbr" commands in the recovery console many times, and despite fixmbr complaining about an "unusual" mbr every time, installing a new one apparently makes no difference. I eventually managed to remove booteasy from the first drive so that "NTLDR is missing" appears straight away, but that is hardly a victory. I even followed Microsoft's instructions in knowledgebase article 318728 and performed a brand new installation of windows into c:\tempwin but even this new installation failed to boot with the same problem. Therefore it would seem that whatever the problem is, Win2k's setup prog either can't fix it or is oblivious to it. It's looking more and more like I'm going to have to reformat this drive as I seem to have no way of getting Win2k operating again, but I'd _really_ like to understand what happened here, not least to ensure I don't repeat the same problems when I come to try and dual- boot again! Apologies for this getting increasingly off-topic, but I can't understand what I've done wrong here as I've done this many times before with 4.x. As ever, any light-shedding would be much appricated :) Thanks. Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
pcm breakage
I haven't seen a message about this show up yet, so I'm thinking it may be an isolated glitch. I rebuilt my system this morning to try and solve some spurious reboots while using X, and ended up with this message being spammed about ten times on startup. /usr/src/sys/vm/uma_core.c:1330: could sleep with "pcm0:play:0" locked from /usr/src/sys/dev/sound/pcm/sound.c:191 When I attempt to play any sound now, an annoying high-pitched whine comes out the speakers until the process is terminated, and the dmesg buffer is overwritten by hundreds of instances of this unhelpful message- "pcm0: pci error". XMMS quits properly, but console commands like 'cat /dev/urandom > /dev/dsp' seem to lock out Ctrl-C and need to be killed from another shell. My exact environment: FreeBSD tomoyo.sakura 5.0-CURRENT FreeBSD 5.0-CURRENT #17: Tue Feb 25 10:14:41 PST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/TOMOYO i386 Some (possibly) relevant devices: acpi0: on motherboard ACPI-0625: *** Info: GPE Block0 defined as GPE0 to GPE15 ACPI-0625: *** Info: GPE Block1 defined as GPE16 to GPE31 pcibios: BIOS version 2.10 Using $PIR table, 8 entries at 0xc00f7760 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcm0: port 0xd800-0xd81f irq 11 at device 11.0 on pci0 pcm0: I hope someone can figure this out. Let me know if I can do more to diagnose the problem. pgp0.pgp Description: PGP signature
Re: problems with umass device
On Mon, Feb 24, 2003 at 03:11:14PM -0700, Ned Wolpert wrote: > I've got a cheesy cigar-pro USB flash-drive (256MB) that works fine on > current (as of last night) Oh! I know that many other umass devices work ;) What I meant to ask was if anybody knew how to make FreeBSD to work with my creative nomad muvo usb flash drive, or help me understand how I can find out what's needed. It's really annoying to have to reboot into otherOS to be able to use it :( -Richard To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: patch for the nVidia driver and -CURRENT
Morten Rodal wrote:
> On Tue, Feb 25, 2003 at 07:28:09PM +0100, Maxime Henrion wrote:
> [snip a lot of the patch]
> > @@ -1431,7 +1442,8 @@
> > SLIST_FOREACH(at, &sc->alloc_list, list) {
> > if (offset >= at->address &&
> > offset < at->address + at->size)
> > -return atop(vtophys(offset));
> > +*paddr = vtophys(offset);
> > +return 0;
> > }
> >
> > return -1;
>
> Should the function return 0 even if the if (offset..) fails? I have
> no clue about the nvidia kernel driver (or kernel stuff at all) but it
> seems to me that the only way the function can return -1 is if the
> list is empty.
And this is consistant with what the code was doing before. This change
is not a functional change, it's just a necessary update due to API
changes.
Cheers,
Maxime
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: patch for the nVidia driver and -CURRENT
On Tue, Feb 25, 2003 at 07:28:09PM +0100, Maxime Henrion wrote:
[snip a lot of the patch]
> @@ -1431,7 +1442,8 @@
> SLIST_FOREACH(at, &sc->alloc_list, list) {
> if (offset >= at->address &&
> offset < at->address + at->size)
> -return atop(vtophys(offset));
> +*paddr = vtophys(offset);
> +return 0;
> }
>
> return -1;
Should the function return 0 even if the if (offset..) fails? I have
no clue about the nvidia kernel driver (or kernel stuff at all) but it
seems to me that the only way the function can return -1 is if the
list is empty.
--
Morten Rodal
pgp0.pgp
Description: PGP signature
RE: /dev/mlx* renamed to /dev/mxl* ??
On 25-Feb-2003 Bob Willcox wrote: > Were the device names for the Mylex devices changed? They used be named > /dev/mlx* but now (since cvs updating and rebuilding my system this > morning) seem to be named /dev/mxl* > > Was this a deliberate name change or am I missing something here? Fixed. :) -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATA problems
It seems Wesley Morgan wrote: > This morning I booted a kernel built last night, and it panicked when > trying to mount the root filesystem after this: > > ad0: READ command timeout tag=0 serv=0 - resetting > ata0: resetting devices .. > ad0: removed from configuration > done > > cvsup'd, built a new kernel, and now instead of a panic I get (with some > extra stuff): Disable DMA for now, I'm working on a fix for this problem.. Are you willing to test patches to solve this problem ? -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [Fwd: mkisofs | burncd not working in 5.0 ?]
Alexander Leidinger wrote:
Please try the patch in from the mail to -current with the Message-ID
<[EMAIL PROTECTED]> and report if it works for
you.
I've applied the patch included here, but it leads to an error (the .rej
file shows it). I infer from the reject that a "while" has to be
replaced by an "if", and so I've edited it by hand.
The problem is that my system still shows the same behavior as before :(
Maybe I've applied the wrong patch?
CU,
David.
diff -u -2 -r1.81 fifo_vnops.c
--- fifo_vnops.c13 Jan 2003 00:28:57 - 1.81
+++ fifo_vnops.c9 Feb 2003 17:32:16 -
@@ -227,5 +227,5 @@
}
if ((ap->a_mode & FREAD) && (ap->a_mode & O_NONBLOCK) == 0) {
- while (fip->fi_writers == 0) {
+ if (fip->fi_writers == 0) {
VOP_UNLOCK(vp, 0, td);
error = tsleep((caddr_t)&fip->fi_readers,
@@ -234,4 +234,9 @@
if (error)
goto bad;
+ /*
+* We must have got woken up because we had a writer.
+* That (and not still having one) is the condition
+* that we must wait for.
+*/
}
}
@@ -243,16 +248,16 @@
}
} else {
- while (fip->fi_readers == 0) {
+ if (fip->fi_readers == 0) {
VOP_UNLOCK(vp, 0, td);
- /*
-* XXX: Some race I havn't located is solved
-* by timing out after a sec. Race seen when
-* sendmail hangs here during boot /phk
-*/
error = tsleep((caddr_t)&fip->fi_writers,
- PCATCH | PSOCK, "fifoow", hz);
+ PCATCH | PSOCK, "fifoow", 0);
vn_lock(vp, LK_EXCLUSIVE | LK_RETRY, td);
if (error)
goto bad;
+ /*
+* We must have got woken up because we had
+* a reader. That (and not still having one)
+* is the condition that we must wait for.
+*/
}
}
***
*** 227,231
}
if ((ap->a_mode & FREAD) && (ap->a_mode & O_NONBLOCK) == 0) {
- while (fip->fi_writers == 0) {
VOP_UNLOCK(vp, 0, td);
error = tsleep((caddr_t)&fip->fi_readers,
--- 227,231
}
if ((ap->a_mode & FREAD) && (ap->a_mode & O_NONBLOCK) == 0) {
+ if (fip->fi_writers == 0) {
VOP_UNLOCK(vp, 0, td);
error = tsleep((caddr_t)&fip->fi_readers,
/dev/mlx* renamed to /dev/mxl* ??
Were the device names for the Mylex devices changed? They used be named /dev/mlx* but now (since cvs updating and rebuilding my system this morning) seem to be named /dev/mxl* Was this a deliberate name change or am I missing something here? Thanks, Bob -- Bob WillcoxWe seem to have forgotten the simple truth that [EMAIL PROTECTED] reason is never perfect. Only non-sense attains Austin, TX perfection. -- Poul Henningsen [1894-1967] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ATA problems
This morning I booted a kernel built last night, and it panicked when trying to mount the root filesystem after this: ad0: READ command timeout tag=0 serv=0 - resetting ata0: resetting devices .. ad0: removed from configuration done cvsup'd, built a new kernel, and now instead of a panic I get (with some extra stuff): atapci0: port 0xeff0-0xefff at device 4.0 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 ata1-slave: timeout waiting for interrupt ata1-slave: ATAPI identify failed ad0: 28615MB [58140/16/63] at ata0-master UDMA66 acd0: CD-RW at ata1-master PIO4 ad0: READ command timeout tag=0 serv=0 - resetting ata0: resetting devices .. done Mounting root from ufs:/dev/ad0s2a setrootbyname failed ffs_mountroot: can't find rootvp Root mount failed: 6 Manual root filesystem specification: : Mount using filesystem eg. ufs:da0s1a ? List valid disk boot devices Abort manual input mountroot> ufs:ad0s2a Mounting root from ufs:ad0s2a setrootbyname failed ffs_mountroot: can't find rootvp Root mount failed: 6 :( -- Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
panic: bwrite: buffer is not busy
FYI,
Panic with sources from Feb. 20th 02:00 CET.
FreeBSD talisker 5.0-CURRENT FreeBSD 5.0-CURRENT #1: Thu Feb 20 22:42:15 CET 2003
[EMAIL PROTECTED]:/usr/src/sys/i386/compile/TALISKER i386
[EMAIL PROTECTED]:/home/patric$ gdb -k /sys/i386/compile/TALISKER/kernel.debug
/var/crash/vmcore.3
GNU gdb 5.2.1 (FreeBSD)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-undermydesk-freebsd"...
panic: bwrite: buffer is not busy???
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x1d82099
fault code = supervisor write, page not present
instruction pointer = 0x8:0xc02dd53c
stack pointer = 0x10:0xd68edc68
frame pointer = 0x10:0xd68edc90
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 = 13 (swi6: tty:sio clock)
trap number = 12
panic: page fault
Stack backtrace:
syncing disks, buffers remaining... panic: bwrite: buffer is not busy???
Uptime: 8h36m41s
Dumping 511 MB
ata0: resetting devices ..
done
16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368
384 400 416 432 448 464 480 496
---
#0 doadump () at ../../../kern/kern_shutdown.c:239
239 dumping++;
(kgdb) bt
#0 doadump () at ../../../kern/kern_shutdown.c:239
#1 0xc0257439 in boot (howto=260) at ../../../kern/kern_shutdown.c:371
#2 0xc02576a3 in panic () at ../../../kern/kern_shutdown.c:542
#3 0xc029be52 in bwrite (bp=0xce6ccfa8) at ../../../kern/vfs_bio.c:842
#4 0xc029d611 in vfs_bio_awrite (bp=0xce6ccfa8) at ../../../kern/vfs_bio.c:1724
#5 0xc02a4fa7 in vop_stdfsync (ap=0xd68eda60) at ../../../kern/vfs_default.c:755
#6 0xc020f3d0 in spec_fsync (ap=0xd68eda60) at ../../../fs/specfs/spec_vnops.c:422
#7 0xc020e8a8 in spec_vnoperate (ap=0x0) at ../../../fs/specfs/spec_vnops.c:123
#8 0xc0323b27 in ffs_sync (mp=0xc4208600, waitfor=2, cred=0xc1543e80, td=0xc04091a0)
at vnode_if.h:612
#9 0xc02b27cb in sync (td=0xc04091a0, uap=0x0) at ../../../kern/vfs_syscalls.c:138
#10 0xc025701c in boot (howto=256) at ../../../kern/kern_shutdown.c:280
#11 0xc02576a3 in panic () at ../../../kern/kern_shutdown.c:542
#12 0xc037ed42 in trap_fatal (frame=0xd68edc28, eva=0) at ../../../i386/i386/trap.c:844
#13 0xc037ea22 in trap_pfault (frame=0xd68edc28, usermode=0, eva=30941337) at
../../../i386/i386/trap.c:758
#14 0xc037e510 in trap (frame=
{tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = -1070738224, tf_esi = -1001969344,
tf_ebp = -695280496, tf_isp = -695280556, tf_ebx = 30941133, tf_edx = -1051358400,
tf_ecx = -1001969304, tf_eax = 4, tf_trapno = 12, tf_err = 2, tf_eip = -1070738116,
tf_cs = 8, tf_eflags = 66050, tf_esp = -1071263219, tf_ss = -1069485760}) at
../../../i386/i386/trap.c:445
#15 0xc036e818 in calltrap () at {standard input}:96
#16 0xc02670e5 in softclock (dummy=0x0) at ../../../kern/kern_timeout.c:195
#17 0xc02432a1 in ithread_loop (arg=0xc1555e80) at ../../../kern/kern_intr.c:536
#18 0xc0242193 in fork_exit (callout=0xc02430d0 , arg=0x0, frame=0x0) at
../../../kern/kern_fork.c:878
(kgdb) f 17
#17 0xc02432a1 in ithread_loop (arg=0xc1555e80) at ../../../kern/kern_intr.c:536
536 ih->ih_handler(ih->ih_argument);
(kgdb) l
531 mtx_unlock(&ithd->it_lock);
532 goto restart;
533 }
534 if ((ih->ih_flags & IH_MPSAFE) == 0)
535 mtx_lock(&Giant);
536 ih->ih_handler(ih->ih_argument);
537 if ((ih->ih_flags & IH_MPSAFE) == 0)
538 mtx_unlock(&Giant);
539 }
540 }
(kgdb) p ih->ih_argument
$1 = (void *) 0x0
HAND,
Patric
--
The problem with troubleshooting is that trouble shoots back.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
TCP stack panic (panic: bremfree: bp 0xc7743f60 not locked)
This is just not my day. Today's (25/03) kernel:
savecore: reboot after panic: bremfree: bp 0xc7743f60 not locked
Feb 25 16:48:39 dcs savecore: reboot after panic: bremfree: bp
0xc7743f60 not lo
cked
savecore: writing core to vmcore.5
[EMAIL PROTECTED]:/root$ gdb -k /var/crash/kernel.5 /var/crash/vmcore.5
GNU gdb 5.2.1 (FreeBSD)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-undermydesk-freebsd"...
panic: bremfree: bp 0xc7743f60 not locked
panic messages:
---
panic: headlocked should be 0
syncing disks, buffers remaining... panic: bremfree: bp 0xc7743f60 not
locked
Uptime: 8m11s
Dumping 255 MB
ata0: resetting devices ..
done
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:239
239 dumping++;
(kgdb) bt full
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:239
No locals.
#1 0xc01eace7 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:371
No locals.
#2 0xc01eaf53 in panic () at /usr/src/sys/kern/kern_shutdown.c:542
td = (struct thread *) 0xc0ec8c30
bootopt = 260
newpanic = 0
buf = "bremfree: bp 0xc7743f60 not locked", '\0'
#3 0xc022cde7 in bremfreel (bp=0xc7743f60) at
/usr/src/sys/kern/vfs_bio.c:680
old_qindex = 3
#4 0xc022cd55 in bremfree (bp=0x0) at /usr/src/sys/kern/vfs_bio.c:667
No locals.
#5 0xc022f073 in vfs_bio_awrite (bp=0x3) at
/usr/src/sys/kern/vfs_bio.c:1765
i = 6
j = -948682708
lblkno = 196800
vp = (struct vnode *) 0xc26b7000
ncl = 0
nwritten = -948682912
size = -1033146368
maxcl = 0
#6 0xc0236316 in vop_stdfsync (ap=0xcd2b1a34)
at /usr/src/sys/kern/vfs_default.c:755
vp = (struct vnode *) 0xc26b7000
bp = (struct buf *) 0xc7743f60
nbp = (struct buf *) 0x0
error = 0
maxretry = 100
#7 0xc01a38c0 in spec_fsync (ap=0xcd2b1a34)
at /usr/src/sys/fs/specfs/spec_vnops.c:422
No locals.
#8 0xc01a2ce8 in spec_vnoperate (ap=0x0)
at /usr/src/sys/fs/specfs/spec_vnops.c:123
No locals.
#9 0xc028e6f7 in ffs_sync (mp=0xc25cd400, waitfor=2, cred=0xc0eb7e80,
td=0xc034c640) at vnode_if.h:612
nvp = (struct vnode *) 0x0
vp = (struct vnode *) 0xcd2b1a34
devvp = (struct vnode *) 0xcd2b1a34
ip = (struct inode *) 0x0
ump = (struct ufsmount *) 0xc26b3200
fs = (struct fs *) 0xc2613800
error = -1070283200
count = 0
wait = 0
lockreq = 18
allerror = 0
#10 0xc024222b in sync (td=0xc034c640, uap=0x0)
at /usr/src/sys/kern/vfs_syscalls.c:138
mp = (struct mount *) 0xc25cd400
nmp = (struct mount *) 0x0
asyncflag = 0
#11 0xc01ea8ec in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:280
bp = (struct buf *) 0x0
iter = -1058239440
nbusy = -1058250624
pbusy = -1070448168
subiter = -1058250624
#12 0xc01eaf53 in panic () at /usr/src/sys/kern/kern_shutdown.c:542
td = (struct thread *) 0xc0ec8c30
bootopt = 256
newpanic = 1
buf = "bremfree: bp 0xc7743f60 not locked", '\0'
#13 0xc02670a8 in tcp_input (m=0xc0eddb00, off0=20)
at /usr/src/sys/netinet/tcp_input.c:2251
th = (struct tcphdr *) 0xc1366034
ip = (struct ip *) 0xc1366020
ipov = (struct ipovly *) 0x0
inp = (struct inpcb *) 0xc28060e4
optp = (u_char *) 0xc1366048 "\001\001\b\n!Õ}»"
optlen = 12
len = -1025473848
tlen = 0
off = -1025473848
drop_hdrlen = 52
tp = (struct tcpcb *) 0xc2e082c8
thflags = 0
so = (struct socket *) 0xc2da5400
todrop = -1025473848
acked = -1025473848
ourfinisacked = -1025473848
needoutput = 0
tiwin = 31856
to = {to_flags = 1, to_tsval = 567639483, to_tsecr = 489925,
to_cc = 0, to_ccecho = 0, to_mss = 0, to_requested_s_scale = 0 '\0',
to_pad = 0 '\0'}
taop = (struct rmxp_tao *) 0xc2e082c8
tao_noncached = {tao_cc = 3223375443, tao_ccsent = 3224899888,
tao_mssopt = 4840}
headlocked = 1
next_hop = (struct sockaddr_in *) 0x0
rstreason = -1025473848
#14 0xc02608e6 in ip_input (m=0xc0eddb00)
at /usr/src/sys/netinet/ip_input.c:947
ip = (struct ip *) 0xc1366020
fp = (struct ipq *) 0xc26e8400
ia = (struct in_ifaddr *) 0xc26e8400
ifa = (struct ifaddr *) 0x0
i = 0
hlen = 20
checkif = 1
sum = 0
pkt_dst = {s_addr = 100794378}
divert_info = 0
args = {m = 0xc03a4738, oif = 0x0, next_hop = 0x0, rule = 0x0,
eh = 0x0, ro = 0xcd2b1cb8, dst = 0xc0359d54, flags = 962, f_id = {
dst_ip = 3224554013, src_ip = 3442154664, dst_port = 5168,
src_port = 49182, proto = 84 'T', flags = 157 '\235'}, divert_rule = 0,
retval = 3224515833}
#15 0xc0260991 in ipintr () at /usr/src/sys/netinet/ip_input.c:965
m = (struct mbuf *) 0xc0eddb00
#16 0xc0254814 in swi_net (dummy=0x0) at /usr/src/sys/net/netisr.c:97
pollmore = 0
bits = 4
i = 2
#17 0xc01c9a72 in ithread_loop (arg=0xc0ec6100)
at /usr/src/sys/kern/kern_intr.c:536
ithd = (struct ithd *) 0xc0ec6100
ih = (struct intrhand
Re: patch for the nVidia driver and -CURRENT
Maxime Henrion wrote:
--X1bOJ3K7DJ5YkBrT
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Hi all,
Recent interface changes made the nVidia driver unbuildable on -CURRENT.
The attached patch should make it work as it used to. Please let me
know if it doesn't.
Yes! [Big kiss to Maxime] Thank you!
The only thing I needed to do to make it work was to delete this line
from nv-freebsd.h:
#error This driver does not support FreeBSD 5.0/-CURRENT!
As long as you are patching you may as well patch that one also, yes?
--X1bOJ3K7DJ5YkBrT
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="nvidia.patch"
diff -u NVIDIA_FreeBSD-1.0-3203/src/nv-freebsd.h nvidia/src/nv-freebsd.h
--- NVIDIA_FreeBSD-1.0-3203/src/nv-freebsd.h Wed Oct 30 15:30:58 2002
+++ nvidia/src/nv-freebsd.h Tue Feb 25 00:00:48 2003
@@ -86,6 +83,7 @@
#if __FreeBSD_version >= 50
#include
+#include
#include
#include
@@ -306,7 +304,8 @@
intnvidia_open_dev (struct nvidia_softc *);
intnvidia_close_ctl (dev_t, d_thread_t *);
intnvidia_close_dev (struct nvidia_softc *, dev_t, d_thread_t *);
-intnvidia_mmap_dev (struct nvidia_softc *, vm_offset_t);
+intnvidia_mmap_dev (struct nvidia_softc *, vm_offset_t,
+vm_offset_t *);
#endif /* __NV_FREEBSD_H__ */
diff -u NVIDIA_FreeBSD-1.0-3203/src/nvidia_dev.c nvidia/src/nvidia_dev.c
--- NVIDIA_FreeBSD-1.0-3203/src/nvidia_dev.c Wed Oct 30 15:30:58 2002
+++ nvidia/src/nvidia_dev.c Mon Feb 24 23:59:21 2003
@@ -135,6 +135,7 @@
int nvidia_dev_mmap(
dev_t dev,
vm_offset_t offset,
+vm_offset_t *paddr,
int nprot
)
{
@@ -148,7 +149,7 @@
nv = sc->nv_state;
nv_lock_api(nv);
-status = nvidia_mmap_dev(sc, offset);
+status = nvidia_mmap_dev(sc, offset, paddr);
nv_unlock_api(nv);
return status;
diff -u NVIDIA_FreeBSD-1.0-3203/src/nvidia_subr.c nvidia/src/nvidia_subr.c
--- NVIDIA_FreeBSD-1.0-3203/src/nvidia_subr.c Wed Oct 30 15:30:58 2002
+++ nvidia/src/nvidia_subr.c Tue Feb 25 00:00:14 2003
@@ -1401,7 +1405,8 @@
int nvidia_mmap_dev(
struct nvidia_softc *sc,
-vm_offset_t offset
+vm_offset_t offset,
+vm_offset_t *paddr
)
{
nv_alloc_t *at;
@@ -1412,14 +1417,20 @@
* are physical addresses and mapped into user-space directly. We can
* only do some basic sanity checking here.
*/
-if (IS_FB_OFFSET(nv, offset, PAGE_SIZE))
-return atop(offset);
+if (IS_FB_OFFSET(nv, offset, PAGE_SIZE)) {
+*paddr = offset;
+return 0;
+}
-if (IS_REG_OFFSET(nv, offset, PAGE_SIZE))
-return atop(offset);
+if (IS_REG_OFFSET(nv, offset, PAGE_SIZE)) {
+*paddr = offset;
+return 0;
+}
-if (IS_AGP_OFFSET(nv, offset, PAGE_SIZE))
-return atop(offset);
+if (IS_AGP_OFFSET(nv, offset, PAGE_SIZE)) {
+*paddr = offset;
+return 0;
+}
/*
* If the offset does not fall into any of the relevant apertures, we
@@ -1431,7 +1442,8 @@
SLIST_FOREACH(at, &sc->alloc_list, list) {
if (offset >= at->address &&
offset < at->address + at->size)
-return atop(vtophys(offset));
+*paddr = vtophys(offset);
+return 0;
}
return -1;
--X1bOJ3K7DJ5YkBrT--
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: mac_mls still panics
Question on both of these: could you inspect the struct ifnet pointer on the mbuf and see what interface they originated from? Also, the dumps are still showing NULL local variables where it should not be possible -- does manual inspection of the variables in the debugger reveal different values (ifnetlabel, mbuflabel, etc). You might want to see if compiling with -O0 gives better results, as it will force memory to be allocated for all local variables, I believe. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories On Tue, 25 Feb 2003, Daniel C. Sobral wrote: > No, it didn't fix the problem. I must have mixed kernels when I tested. > Two more panics attached (the first seems to have been a double panic). > > -- > Daniel C. Sobral > Gerência de Operações > Divisão de Comunicação de Dados > Coordenação de Segurança > TCO > Fones: 55-61-313-7654/Cel: 55-61-9618-0904 > E-mail: [EMAIL PROTECTED] > [EMAIL PROTECTED] > [EMAIL PROTECTED] > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
mac_mls still panics
No, it didn't fix the problem. I must have mixed kernels when I tested.
Two more panics attached (the first seems to have been a double panic).
--
Daniel C. Sobral
Gerência de Operações
Divisão de Comunicação de Dados
Coordenação de Segurança
TCO
Fones: 55-61-313-7654/Cel: 55-61-9618-0904
E-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
savecore: reboot after panic: bremfree: bp 0xc775d6f8 not locked
Feb 25 14:08:55 dcs savecore: reboot after panic: bremfree: bp 0xc775d6f8 not locked
savecore: writing core to vmcore.3
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:239
No locals.
#1 0xc01eae77 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:371
No locals.
#2 0xc01eb0e3 in panic () at /usr/src/sys/kern/kern_shutdown.c:542
td = (struct thread *) 0xc0ecbc30
bootopt = 260
newpanic = 0
buf = "bremfree: bp 0xc775d6f8 not locked\0le", '\0'
#3 0xc022cf77 in bremfreel (bp=0xc775d6f8) at /usr/src/sys/kern/vfs_bio.c:680
old_qindex = 3
#4 0xc022cee5 in bremfree (bp=0x0) at /usr/src/sys/kern/vfs_bio.c:667
No locals.
#5 0xc022f203 in vfs_bio_awrite (bp=0x3) at /usr/src/sys/kern/vfs_bio.c:1765
i = 6
j = -948578364
lblkno = 196800
vp = (struct vnode *) 0xc26c4000
ncl = 0
nwritten = -948578568
size = -1033093120
maxcl = -948543368
#6 0xc02364a6 in vop_stdfsync (ap=0xcd2a784c)
at /usr/src/sys/kern/vfs_default.c:755
vp = (struct vnode *) 0xc26c4000
bp = (struct buf *) 0xc775d6f8
nbp = (struct buf *) 0xc7766078
error = 0
maxretry = 100
#7 0xc01a3a50 in spec_fsync (ap=0xcd2a784c)
at /usr/src/sys/fs/specfs/spec_vnops.c:422
No locals.
#8 0xc01a2e78 in spec_vnoperate (ap=0x0)
at /usr/src/sys/fs/specfs/spec_vnops.c:123
No locals.
#9 0xc0296877 in ffs_sync (mp=0xc25cd400, waitfor=2, cred=0xc0eb7e00,
td=0xc0355c80) at vnode_if.h:612
nvp = (struct vnode *) 0x0
vp = (struct vnode *) 0xcd2a784c
devvp = (struct vnode *) 0xcd2a784c
ip = (struct inode *) 0x0
ump = (struct ufsmount *) 0xc26c0200
fs = (struct fs *) 0xc0ebc800
error = -1070244736
count = 0
wait = 0
lockreq = 18
allerror = 0
#10 0xc02423bb in sync (td=0xc0355c80, uap=0x0)
at /usr/src/sys/kern/vfs_syscalls.c:138
mp = (struct mount *) 0xc25cd400
nmp = (struct mount *) 0x0
asyncflag = 0
#11 0xc01eaa7c in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:280
bp = (struct buf *) 0x0
iter = -1058227152
nbusy = -1058239232
pbusy = -1070415031
subiter = -1058239232
#12 0xc01eb0e3 in panic () at /usr/src/sys/kern/kern_shutdown.c:542
td = (struct thread *) 0xc0ecbc30
bootopt = 256
newpanic = 1
buf = "bremfree: bp 0xc775d6f8 not locked\0le", '\0'
#13 0xc02772d4 in mac_mls_single_in_range (single=0x0, range=0xc2605f00)
at /usr/src/sys/security/mac_mls/mac_mls.c:225
No locals.
#14 0xc0278d16 in mac_mls_check_ifnet_transmit (ifnet=0xc25ebc00,
ifnetlabel=0x0, m=0xc0edab00, mbuflabel=0x0)
at /usr/src/sys/security/mac_mls/mac_mls.c:1462
p = (struct mac_mls *) 0x0
i = (struct mac_mls *) 0x0
#15 0xc01dad8a in mac_check_ifnet_transmit (ifnet=0xc25ebc00, mbuf=0xc0edab00)
at /usr/src/sys/kern/kern_mac.c:2269
mpc = (struct mac_policy_conf *) 0xc2605f00
error = 0
#16 0xc0252818 in ether_output (ifp=0xc25ebc00, m=0xc0edab00, dst=0xc26cc390,
rt0=0xc2ee6400) at /usr/src/sys/net/if_ethersubr.c:157
type = 0
error = -1058165932
hdrcmplt = 0
esrc = "\0\0\0\0\024"
edst = "T«íÀÌy"
rt = (struct rtentry *) 0xc0edab00
eh = (struct ether_header *) 0xc0edab54
loop_copy = 0
ac = (struct arpcom *) 0xc25ebc00
#17 0xc0262815 in ip_output (m0=0xc0edab00, opt=0xc0edab54, ro=0xc28484b0,
flags=0, imo=0x0, inp=0xc2848474) at /usr/src/sys/netinet/ip_output.c:1015
ip = (struct ip *) 0xc0edab54
mhip = (struct ip *) 0xcd2a7a58
ifp = (struct ifnet *) 0xc25ebc00
m = (struct mbuf *) 0xc2ee6400
hlen = 20
len = -1071770176
off = -1070040896
error = 0
dst = (struct sockaddr_in *) 0xc26cc390
ia = (struct in_ifaddr *) 0xc2608e00
isbroadcast = 0
sw_csum = 1
pkt_dst = {s_addr = 2770911040}
args = {m = 0xcd2a7a7c, oif = 0xc01d182b, next_hop = 0x0, rule = 0x0,
eh = 0x0, ro = 0x2cf, dst = 0xc0edab00, flags = 2, f_id = {dst_ip = 1,
src_ip = 3442113188, dst_port = 20143, src_port = 49184, proto = 0 '\0',
flags = 171 '«'}, divert_rule = 0, retval = 2}
src_was_INADDR_ANY = 0
#18 0xc026a74c in tcp_twrespond (tw=0xc2f7d000, flags=16)
at /usr/src/sys/netinet/tcp_subr.c:1776
inp = (struct inpcb *) 0xc2848474
th = (struct tcphdr *) 0xc0edab68
m = (struct mbuf *) 0x
Re: Checksum offload support for Intel 82550/82551
Hello, > Yes, it's me. I'm still alive. It's great to hear that one of the most talented FreeBSD hackers is back in business :) Does this means that you can afford some time to investigate the problems regarding your old software? I mean ng_fec primarily, because I couldn't get help in the past few months/years(?)... You may know, or not it is now part of FreeBSD, the only problem is that it does not work. I filed a PR (kern/46720) about a month ago, but haven't gotten too much response back. On these lists I think there is a consensus (search the archives :) that the FEC implementation is a good thing. Another problem, which I faced years ago that if you want to use .1q tagged packets on a FEC interface, it just does not works. There are more verbose details on these lists too. Are there any chances to get these fixed? Thanks in advance! --[ Free Software ISOs - http://www.fsn.hu/?f=download ]-- Attila Nagy e-mail: [EMAIL PROTECTED] Free Software Network (FSN.HU)phone @work: +361 210 1415 (194) cell.: +3630 306 6758 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: LAN support for nVidia nForce2
Windows XP says that it's NVIDIA nForce MCP Networking Controller, if it can help. Sincerely, Maxim M. Kazachek mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] On Mon, 24 Feb 2003, David O'Brien wrote: >On Mon, Feb 24, 2003 at 04:09:11PM +0600, Maxim M. Kazachek wrote: >> Is there any support of nVidia's nForce2 integrated LAN >> controller? >> Also I have following message during device probe: >> pcm0: measured ac97 link rate at 292571428 Hz > >Should be -- I committed some support for it. >rev 1.123 src/sys/pci/if_xl.c > >What sources are you using? > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
patch for the nVidia driver and -CURRENT
Hi all,
Recent interface changes made the nVidia driver unbuildable on -CURRENT.
The attached patch should make it work as it used to. Please let me
know if it doesn't.
Cheers,
Maxime
diff -u NVIDIA_FreeBSD-1.0-3203/src/nv-freebsd.h nvidia/src/nv-freebsd.h
--- NVIDIA_FreeBSD-1.0-3203/src/nv-freebsd.hWed Oct 30 15:30:58 2002
+++ nvidia/src/nv-freebsd.h Tue Feb 25 00:00:48 2003
@@ -86,6 +83,7 @@
#if __FreeBSD_version >= 50
#include
+#include
#include
#include
@@ -306,7 +304,8 @@
intnvidia_open_dev (struct nvidia_softc *);
intnvidia_close_ctl (dev_t, d_thread_t *);
intnvidia_close_dev (struct nvidia_softc *, dev_t, d_thread_t *);
-intnvidia_mmap_dev (struct nvidia_softc *, vm_offset_t);
+intnvidia_mmap_dev (struct nvidia_softc *, vm_offset_t,
+ vm_offset_t *);
#endif /* __NV_FREEBSD_H__ */
diff -u NVIDIA_FreeBSD-1.0-3203/src/nvidia_dev.c nvidia/src/nvidia_dev.c
--- NVIDIA_FreeBSD-1.0-3203/src/nvidia_dev.cWed Oct 30 15:30:58 2002
+++ nvidia/src/nvidia_dev.c Mon Feb 24 23:59:21 2003
@@ -135,6 +135,7 @@
int nvidia_dev_mmap(
dev_t dev,
vm_offset_t offset,
+vm_offset_t *paddr,
int nprot
)
{
@@ -148,7 +149,7 @@
nv = sc->nv_state;
nv_lock_api(nv);
-status = nvidia_mmap_dev(sc, offset);
+status = nvidia_mmap_dev(sc, offset, paddr);
nv_unlock_api(nv);
return status;
diff -u NVIDIA_FreeBSD-1.0-3203/src/nvidia_subr.c nvidia/src/nvidia_subr.c
--- NVIDIA_FreeBSD-1.0-3203/src/nvidia_subr.c Wed Oct 30 15:30:58 2002
+++ nvidia/src/nvidia_subr.cTue Feb 25 00:00:14 2003
@@ -1401,7 +1405,8 @@
int nvidia_mmap_dev(
struct nvidia_softc *sc,
-vm_offset_t offset
+vm_offset_t offset,
+vm_offset_t *paddr
)
{
nv_alloc_t *at;
@@ -1412,14 +1417,20 @@
* are physical addresses and mapped into user-space directly. We can
* only do some basic sanity checking here.
*/
-if (IS_FB_OFFSET(nv, offset, PAGE_SIZE))
-return atop(offset);
+if (IS_FB_OFFSET(nv, offset, PAGE_SIZE)) {
+*paddr = offset;
+return 0;
+}
-if (IS_REG_OFFSET(nv, offset, PAGE_SIZE))
-return atop(offset);
+if (IS_REG_OFFSET(nv, offset, PAGE_SIZE)) {
+*paddr = offset;
+return 0;
+}
-if (IS_AGP_OFFSET(nv, offset, PAGE_SIZE))
-return atop(offset);
+if (IS_AGP_OFFSET(nv, offset, PAGE_SIZE)) {
+*paddr = offset;
+return 0;
+}
/*
* If the offset does not fall into any of the relevant apertures, we
@@ -1431,7 +1442,8 @@
SLIST_FOREACH(at, &sc->alloc_list, list) {
if (offset >= at->address &&
offset < at->address + at->size)
-return atop(vtophys(offset));
+*paddr = vtophys(offset);
+return 0;
}
return -1;
Re: LAN support for nVidia nForce2
if_xl.c is 1.129 Sincerely, Maxim M. Kazachek mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] On Mon, 24 Feb 2003, David O'Brien wrote: >On Mon, Feb 24, 2003 at 04:09:11PM +0600, Maxim M. Kazachek wrote: >> Is there any support of nVidia's nForce2 integrated LAN >> controller? >> Also I have following message during device probe: >> pcm0: measured ac97 link rate at 292571428 Hz > >Should be -- I committed some support for it. >rev 1.123 src/sys/pci/if_xl.c > >What sources are you using? > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
[bobb@fastmail.fm: Fatal trap 12: page fault while in kernel mode]
- Forwarded message from Bobb Shires <[EMAIL PROTECTED]> - I'm trying to install 5.0-RELEASE on a Gateway Solo 5150 laptop (PII-366/128M), can't seem to get past this situation while booting from the CD: Fatal trap 12: page fault while in kernel mode fault virtual address = 0xc8ea5048 fault code = supervisor read, page not present instruction pointer = 0x8:0xc0246a25 stack pointer = 0x10:0xc885a960 frame pointer = 0x10:0xc885ab8c 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 = 9 (cbb0) trap number = 12 panic: page fault syncing discs, buffers remaining... done Uptime: 1s Terminate ACPI ata1-slave: ATAPI identify retries exceeded Automatic reboot in 15 seconds - press a key on the console to abort Can anyone decipher this for me and suggest a course of action? Thanks!! -- Bobb Shires [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message - End forwarded message - pgp0.pgp Description: PGP signature
Re: performance / /usr/src/UPDATING
> Date: Mon, 24 Feb 2003 13:12:51 +0100 > From: Christoph Kukulies <[EMAIL PROTECTED]> > Sender: [EMAIL PROTECTED] > > > In /usr/src/UPDATING I read that -current is always compiled withlots of debugging > flags on etc. > > Can this be switched off with a single switch in the Makefile? No. It is mostly controlled by your kernel config file. If you look at GENERIC in RELENG_5_0, you can see what is commented out for the 5.0 release and do the same. -current is NOT intended for production (or even near production) services and the debugging stuff is default for good reason, but it's perfectly fine to turn it off if you want to get a feel for the "normal" performance of the software. R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: "NTLDR missing" after 5-RELEASE install
What does your Drive Layout look like? Is your W2k partition FAT32? Has it always been the first partition on the drive, or did you move it, using something like partition magic? Is freeBSD in the extended partition? -Matt On Tue, 2003-02-25 at 11:58, Andrew Boothman wrote: > Quoting Lucas Holt <[EMAIL PROTECTED]>: > > > It probably is. You need to put in the win 2k CD and do a repair on > > your windows install.. unfortunetely this may screw up your freebsd > > install. > > > > On Tuesday, February 25, 2003, at 05:58 AM, Andrew Boothman wrote: > > > > > Hi! > > > > > > I've just installed 5-RELEASE, and I asked for the FreeBSD Boot > > > Manager to be installed on both my HDDs. > > > > > > When the machine boots I'm given options for : > > > > > > F1 - DOS > > > F5 - Drive 2 > > > > > > Hitting F5 takes me to a second menu, where I can boot FreeBSD no > > > problem. My problem is that Win2k will no longer boot Hitting F1 > > > displays a message that, "NTLDR is missing". I've tried all the repair > > > > > options on the Win2k setup disc to no avail I think. > > > > > > I'm sorry this isn't directly FreeBSD related, but I really hope my > > > Win2k installation isn't hosed. > > Thanks for replying! > > I can't understand how the 5.x boot manager has managed to break my windows > boot, i've never had any trouble under 3.x or 4.x, both of which played with > windows perfectly nicely. > > I think i've tried all of the various repair options on the Win2k CD, including > getting it to do a fresh installation into a different folder (c:\tempwin), but > even that failed with the "NTLDR missing" message! However you no longer get > the booteasy (F1 F2) menu anymore, so Windows must have rewritten > something. It still doesn't explain why Win2k still won't boot. > > I'm running out of ideas and I *really* don't want to have to reformat my > windows drive! > > Other than this (fairly major) problem, my 5.0 installation went really well, > even ACPI seems to be working perfectly and I even found a KLD to support my on- > board sound card! :) > > I really want to get windows booting again so I can continue to play with 5.0 > without worrying... > > Any help is much appricated! > > Thanks! > > Andrew > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-questions" in the body of the message -- Matt Smith <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: buildworld dies with Signal 4
Paulius, I had the exact same problem less than a week ago. The solution was the edit my kernel build configuration file and add the following two lines: options DISABLE_PSE options DISABLE_PG_G This changes the VM subsystem so that it uses 4 kB pages instead of the default 4 MB pages. There is a bug in some hardware that only shows up under heavy CPU & memory loading, such as a buildworld incurs. Someone had told me that there is a 10% - 15% performance penalty from doing this, but I don't run the system hard enough to be able to notice. -- Paul A. Howes -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paulius Bulotas Sent: Tuesday, February 25, 2003 11:21 AM To: [EMAIL PROTECTED] Subject: Re: buildworld dies with Signal 4 On 03 02 25, Steve Kargl wrote: > On Tue, Feb 25, 2003 at 05:12:52PM +0200, Paulius Bulotas wrote: > > and I'm trying to make buildworld today, but it crashes in various > > places with Signal 4. > Do you have CPUTYPE=p4? How much memory > is in the computer? You are right, it's CPU: Intel(R) Pentium(R) 4 CPU 1.80GHz (1799.81-MHz 686-class CPU) real memory = 527695872 (503 MB) on Intel 845G motherboard and in make.conf I have CPUTYPE and other compile time options commented out (because some time ago I was unable to build mozilla) sometimes I get Signal 10... Paulius To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: LAN support for nVidia nForce2
I CVSup'd February 24... In addition I want to say that measured ac97 link rate may be 51200 or more that 6 (about 69300 as I can remember) Sincerely, Maxim M. Kazachek mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] On Mon, 24 Feb 2003, David O'Brien wrote: >On Mon, Feb 24, 2003 at 04:09:11PM +0600, Maxim M. Kazachek wrote: >> Is there any support of nVidia's nForce2 integrated LAN >> controller? >> Also I have following message during device probe: >> pcm0: measured ac97 link rate at 292571428 Hz > >Should be -- I committed some support for it. >rev 1.123 src/sys/pci/if_xl.c > >What sources are you using? > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: "NTLDR missing" after 5-RELEASE install
Quoting Lucas Holt <[EMAIL PROTECTED]>: > It probably is. You need to put in the win 2k CD and do a repair on > your windows install.. unfortunetely this may screw up your freebsd > install. > > On Tuesday, February 25, 2003, at 05:58 AM, Andrew Boothman wrote: > > > Hi! > > > > I've just installed 5-RELEASE, and I asked for the FreeBSD Boot > > Manager to be installed on both my HDDs. > > > > When the machine boots I'm given options for : > > > > F1 - DOS > > F5 - Drive 2 > > > > Hitting F5 takes me to a second menu, where I can boot FreeBSD no > > problem. My problem is that Win2k will no longer boot Hitting F1 > > displays a message that, "NTLDR is missing". I've tried all the repair > > > options on the Win2k setup disc to no avail I think. > > > > I'm sorry this isn't directly FreeBSD related, but I really hope my > > Win2k installation isn't hosed. Thanks for replying! I can't understand how the 5.x boot manager has managed to break my windows boot, i've never had any trouble under 3.x or 4.x, both of which played with windows perfectly nicely. I think i've tried all of the various repair options on the Win2k CD, including getting it to do a fresh installation into a different folder (c:\tempwin), but even that failed with the "NTLDR missing" message! However you no longer get the booteasy (F1 F2) menu anymore, so Windows must have rewritten something. It still doesn't explain why Win2k still won't boot. I'm running out of ideas and I *really* don't want to have to reformat my windows drive! Other than this (fairly major) problem, my 5.0 installation went really well, even ACPI seems to be working perfectly and I even found a KLD to support my on- board sound card! :) I really want to get windows booting again so I can continue to play with 5.0 without worrying... Any help is much appricated! Thanks! Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
X server won't start this morning
Just finished a cvsup and rebuild of world/kernel and now my X server refuses to start: (EE) NVIDIA(0): Failed to initialize the NVdriver kernel module! The proprietary nvidia.ko module from nVidia still loads normally with no error messages during system boot. There is also a warning about a 'possible' ulimit on virtual memory available to XFree, but ulimit -a shows no limit on vm, so I'm assuming that is a bogus warning. 'top' shows plenty of unused memory and half a gig of available swap. This was all working perfectly this morning before the cvsup and I've changed nothing in any config files. Anyone else having a similar problem? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: buildworld dies with Signal 4
On 03 02 25, leafy wrote: > On Tue, Feb 25, 2003 at 05:12:52PM +0200, Paulius Bulotas wrote: > > Any idea why this could be happening? > > Maybe I should try make with NOCLEAN=yes? > No, that's the last thing you would want to try. Could you try removing /usr/obj > first and then rebuild world? Well, removing of /usr/obj doesn't help, but NOCLEAN helps a bit ;) Paulius To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: buildworld dies with Signal 4
On 03 02 25, Steve Kargl wrote: > On Tue, Feb 25, 2003 at 05:12:52PM +0200, Paulius Bulotas wrote: > > and I'm trying to make buildworld today, but it crashes in various > > places with Signal 4. > Do you have CPUTYPE=p4? How much memory > is in the computer? You are right, it's CPU: Intel(R) Pentium(R) 4 CPU 1.80GHz (1799.81-MHz 686-class CPU) real memory = 527695872 (503 MB) on Intel 845G motherboard and in make.conf I have CPUTYPE and other compile time options commented out (because some time ago I was unable to build mozilla) sometimes I get Signal 10... Paulius To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
OpenSSL question for id_function()
Hi, I have a question about OpenSSL 0.9.7. On the following web page: http://www.openssl.org/docs/crypto/threads.html "void CRYPTO_set_id_callback(unsigned long (*id_function)(void)); id_function(void) is a function that returns a thread ID. It is not needed on Windows nor on platforms where getpid() returns a different ID for each thread (most notably Linux)." I have some third party C++ code which tries to implement this id_function as: return static_cast(pthread_self()); pthread_self() returns something of type pthread_t. This code works under Linux, because pthread_t is mapped to an integer value. However, on FreeBSD, pthread_t is a pointer to struct pthread, so this code does not compile: OpenSSLPluginI.cpp: In function `long unsigned int IceSSL::idFunction()': OpenSSLPluginI.cpp:153: invalid static_cast from type `pthread*' to type `long unsigned int' Is there a way to implement the id_function() for OpenSSL so that it works portably across FreeBSD and Linux? Thanks. -- Craig Rodrigues http://home.attbi.com/~rodrigc [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: buildworld dies with Signal 4
On Tue, Feb 25, 2003 at 05:12:52PM +0200, Paulius Bulotas wrote: > Any idea why this could be happening? > Maybe I should try make with NOCLEAN=yes? > > TIA > Paulius No, that's the last thing you would want to try. Could you try removing /usr/obj first and then rebuild world? Jiawei -- "Without the userland, the kernel is useless." --inspired by The Tao of Programming To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: OpenSSL should define OPENSSL_THREADS?
On Tue, Feb 25, 2003 at 07:22:09AM -0600, Jacques A. Vidrine wrote: > On Mon, Feb 24, 2003 at 09:58:21PM -0500, Craig Rodrigues wrote: > > Hi, > > > > I ran a cvsup of -CURRENT a few days ago. > > > > I have some code which assumes that OPENSSL_THREADS is defined if > > the OpenSSL version is greater than 0.9.7: > > Should the OpenSSL in FreeBSD be defining OPENSSL_THREADS? > > I think you may be right. OpenSSL 0.9.7's out-of-the box configure > creates an opensslconf.h that would define OPENSSL_THREADS on FreeBSD. > > Mark supplied the opensslconf.h's that are used in the FreeBSD build ... > let's see if this is intentional or not. [cc'd] These kind of macro changes can break backwards compatibility (OpenSSL's fault). If the intent is to minimize breakage of ports and such, I would not be opposed to do something like: #define OPENSSL_THREADS 1 #define THREADS OPENSSL_THREADS/** deprecated */ Would this work? -- Craig Rodrigues http://home.attbi.com/~rodrigc [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: buildworld dies with Signal 4
On Tue, Feb 25, 2003 at 05:12:52PM +0200, Paulius Bulotas wrote: > Hello, > > I'm running -current from Thu Feb 20 09:40:41 EET 2003 > and I'm trying to make buildworld today, but it crashes in various > places with Signal 4. > > Any idea why this could be happening? > Maybe I should try make with NOCLEAN=yes? > Do you have CPUTYPE=p4? How much memory is in the computer? -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: performance / /usr/src/UPDATING
Christoph Kukulies <[EMAIL PROTECTED]> writes: > In /usr/src/UPDATING I read that -current is always compiled > withlots of debugging flags on etc. > > Can this be switched off with a single switch in the Makefile? Not a single switch, but there isn't a whole lot to do. Mainly, you want to turn the J malloc option off by doing # ln -fs j /etc/malloc.conf This should improve userland performance quite a bit, and you don't even need to rebuild - it takes effect immediately (for programs started after the change). As for the kernel, assuming your config is based on GENERIC, you'll want to remove (or comment out) the WITNESS options, and possibly also the INVARIANTS options. Note that if you do get in trouble, the lack of these (especially INVARIANTS) will make debugging much harder. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
buildworld dies with Signal 4
Hello, I'm running -current from Thu Feb 20 09:40:41 EET 2003 and I'm trying to make buildworld today, but it crashes in various places with Signal 4. Any idea why this could be happening? Maybe I should try make with NOCLEAN=yes? TIA Paulius To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Witness This
On Tue, 25 Feb 2003, Daniel C. Sobral wrote: > Robert Watson wrote: > > Ok, I've committed it. Saw your other panic message, hope to look more > > closely today. > > > > BTW, you might consider running with the mac_test module, as it's intended > > to help diagnose label problems through additional assertions. > > Oh. That was not clear to me. I thought it was a module you used for > tests, not something which _helped_ debug other mac policies. Well, it helps debug the MAC Framework's handling of labels by testing lots of assertions about how labels are handled by the framework. It doesn't specifically exercise other policies, but it can generate useful fail-stop behavior for some well-defined failure modes. I.e., it tests that uninitialized labels aren't passed to various entry points, that labels aren't destroyed more than once, etc. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Witness This
Now I think I was premature. It seems there is something unmacish in
this kernel. Sigh. Well, I'll test with a recent source.
Robert Watson wrote:
Ok, I've committed it. Saw your other panic message, hope to look more
closely today.
BTW, you might consider running with the mac_test module, as it's intended
to help diagnose label problems through additional assertions.
Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
[EMAIL PROTECTED] Network Associates Laboratories
On Tue, 25 Feb 2003, Daniel C. Sobral wrote:
No bugs so far with this.
Robert Watson wrote:
Revised patch without typo attached.
Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
[EMAIL PROTECTED] Network Associates Laboratories
Index: tcp_subr.c
===
RCS file: /data/fbsd-cvs/ncvs/src/sys/netinet/tcp_subr.c,v
retrieving revision 1.155
diff -u -r1.155 tcp_subr.c
--- tcp_subr.c 21 Feb 2003 23:17:12 - 1.155
+++ tcp_subr.c 22 Feb 2003 02:44:42 -
@@ -484,7 +484,7 @@
m->m_pkthdr.len = tlen;
m->m_pkthdr.rcvif = (struct ifnet *) 0;
#ifdef MAC
- if (tp != NULL) {
+ if (tp != NULL && tp->t_inpcb != NULL) {
/*
* Packet is associated with a socket, so allow the
* label of the response to reflect the socket label.
--
Daniel C. Sobral (8-DCS)
Gerencia de Operacoes
Divisao de Comunicacao de Dados
Coordenacao de Seguranca
TCO
Fones: 55-61-313-7654/Cel: 55-61-9618-0904
E-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Outros:
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
I disagree with what you say, but will defend
to the death your right to tell such LIES!
--
Daniel C. Sobral (8-DCS)
Gerencia de Operacoes
Divisao de Comunicacao de Dados
Coordenacao de Seguranca
TCO
Fones: 55-61-313-7654/Cel: 55-61-9618-0904
E-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Outros:
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
The world needs more people like us and fewer like them.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: the ata driver is broken
It seems Takahashi Yoshihiro wrote: > I got the following error. The kernel config has no pci device but > ATA_NOPCI option. Fixed. I just completely forgot that ISA only systems exists... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Witness This
Robert Watson wrote:
Ok, I've committed it. Saw your other panic message, hope to look more
closely today.
BTW, you might consider running with the mac_test module, as it's intended
to help diagnose label problems through additional assertions.
Oh. That was not clear to me. I thought it was a module you used for
tests, not something which _helped_ debug other mac policies.
Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
[EMAIL PROTECTED] Network Associates Laboratories
On Tue, 25 Feb 2003, Daniel C. Sobral wrote:
No bugs so far with this.
Robert Watson wrote:
Revised patch without typo attached.
Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
[EMAIL PROTECTED] Network Associates Laboratories
Index: tcp_subr.c
===
RCS file: /data/fbsd-cvs/ncvs/src/sys/netinet/tcp_subr.c,v
retrieving revision 1.155
diff -u -r1.155 tcp_subr.c
--- tcp_subr.c 21 Feb 2003 23:17:12 - 1.155
+++ tcp_subr.c 22 Feb 2003 02:44:42 -
@@ -484,7 +484,7 @@
m->m_pkthdr.len = tlen;
m->m_pkthdr.rcvif = (struct ifnet *) 0;
#ifdef MAC
- if (tp != NULL) {
+ if (tp != NULL && tp->t_inpcb != NULL) {
/*
* Packet is associated with a socket, so allow the
* label of the response to reflect the socket label.
--
Daniel C. Sobral (8-DCS)
Gerencia de Operacoes
Divisao de Comunicacao de Dados
Coordenacao de Seguranca
TCO
Fones: 55-61-313-7654/Cel: 55-61-9618-0904
E-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Outros:
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
I disagree with what you say, but will defend
to the death your right to tell such LIES!
--
Daniel C. Sobral (8-DCS)
Gerencia de Operacoes
Divisao de Comunicacao de Dados
Coordenacao de Seguranca
TCO
Fones: 55-61-313-7654/Cel: 55-61-9618-0904
E-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Outros:
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Don't hate yourself in the morning -- sleep till noon.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Witness This
Ok, I've committed it. Saw your other panic message, hope to look more
closely today.
BTW, you might consider running with the mac_test module, as it's intended
to help diagnose label problems through additional assertions.
Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
[EMAIL PROTECTED] Network Associates Laboratories
On Tue, 25 Feb 2003, Daniel C. Sobral wrote:
> No bugs so far with this.
>
> Robert Watson wrote:
> > Revised patch without typo attached.
> >
> > Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
> > [EMAIL PROTECTED] Network Associates Laboratories
> >
> > Index: tcp_subr.c
> > ===
> > RCS file: /data/fbsd-cvs/ncvs/src/sys/netinet/tcp_subr.c,v
> > retrieving revision 1.155
> > diff -u -r1.155 tcp_subr.c
> > --- tcp_subr.c 21 Feb 2003 23:17:12 - 1.155
> > +++ tcp_subr.c 22 Feb 2003 02:44:42 -
> > @@ -484,7 +484,7 @@
> > m->m_pkthdr.len = tlen;
> > m->m_pkthdr.rcvif = (struct ifnet *) 0;
> > #ifdef MAC
> > - if (tp != NULL) {
> > + if (tp != NULL && tp->t_inpcb != NULL) {
> > /*
> > * Packet is associated with a socket, so allow the
> > * label of the response to reflect the socket label.
>
>
> --
> Daniel C. Sobral (8-DCS)
> Gerencia de Operacoes
> Divisao de Comunicacao de Dados
> Coordenacao de Seguranca
> TCO
> Fones: 55-61-313-7654/Cel: 55-61-9618-0904
> E-mail: [EMAIL PROTECTED]
> [EMAIL PROTECTED]
> [EMAIL PROTECTED]
>
> Outros:
> [EMAIL PROTECTED]
> [EMAIL PROTECTED]
> [EMAIL PROTECTED]
>
> I disagree with what you say, but will defend
> to the death your right to tell such LIES!
>
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
sparc64 tinderbox failure
Tinderbox FAQ: http://people.FreeBSD.org/~mike/tinderbox.html -- >>> Rebuilding the temporary build tree -- >>> stage 1: bootstrap tools -- >>> stage 2: cleaning up the object tree -- >>> stage 2: rebuilding the object tree -- >>> stage 2: build tools -- >>> stage 3: cross tools -- >>> stage 4: populating >>> /tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include -- >>> stage 4: building libraries -- >>> stage 4: make dependencies -- >>> stage 4: building everything.. -- >>> Kernel build for GENERIC started on Tue Feb 25 08:17:29 EST 2003 -- ===> hme /tinderbox/sparc64/src/sys/kern/vfs_bio.c: In function `bdwrite': /tinderbox/sparc64/src/sys/kern/vfs_bio.c:1040: too few arguments to function `BUF_LOCK' *** Error code 1 Stop in /tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
the ata driver is broken
I got the following error. The kernel config has no pci device but ATA_NOPCI option. cc -c -Os -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/dev -I/usr/src/sys/contrib/dev/acpica -I/usr/src/sys/contrib/ipfilter -D_KERNEL -include opt_global.h -fno-common -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror /usr/src/sys/dev/ata/ata-isa.c cc1: warnings being treated as errors /usr/src/sys/dev/ata/ata-isa.c:117: warning: no previous prototype for `ata_dmaalloc' /usr/src/sys/dev/ata/ata-isa.c:123: warning: no previous prototype for `ata_dmafree' /usr/src/sys/dev/ata/ata-isa.c:128: warning: no previous prototype for `ata_dmafreetags' /usr/src/sys/dev/ata/ata-isa.c:133: warning: no previous prototype for `ata_dmainit' /usr/src/sys/dev/ata/ata-isa.c:138: warning: no previous prototype for `ata_dmasetup' /usr/src/sys/dev/ata/ata-isa.c:144: warning: no previous prototype for `ata_dmastart' /usr/src/sys/dev/ata/ata-isa.c:150: warning: no previous prototype for `ata_dmadone' /usr/src/sys/dev/ata/ata-isa.c:156: warning: no previous prototype for `ata_dmastatus' *** Error code 1 --- TAKAHASHI Yoshihiro <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: OpenSSL should define OPENSSL_THREADS?
On Mon, Feb 24, 2003 at 09:58:21PM -0500, Craig Rodrigues wrote: > Hi, > > I ran a cvsup of -CURRENT a few days ago. > > I have some code which assumes that OPENSSL_THREADS is defined if > the OpenSSL version is greater than 0.9.7: > > #define OPENSSL_THREAD_DEFINES > #include > #include > #if OPENSSL_VERSION_NUMBER < 0x0090700fL > # if !defined(THREADS) > # error "Thread support not enabled" > # endif > #else > # if !defined(OPENSSL_THREADS) > # error "Thread support not enabled" > # endif > #endif > > > Should the OpenSSL in FreeBSD be defining OPENSSL_THREADS? I think you may be right. OpenSSL 0.9.7's out-of-the box configure creates an opensslconf.h that would define OPENSSL_THREADS on FreeBSD. Mark supplied the opensslconf.h's that are used in the FreeBSD build ... let's see if this is intentional or not. [cc'd] Cheers, -- Jacques A. Vidrine <[EMAIL PROTECTED]> http://www.celabo.org/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
spontaneous reboot while dump -0uaLf - /var on a UFS2 FS in5.0-RELEASE
I just did a dump over the network via ftp using the command: put "|dump -0uaLf - /var | gzip -1" var.dump.gz /var is a UFS2 FS with soft-updates, and the system is 5.0-RELEASE. I got a short pause, maybe 5 seconds, and then the system rebooted spontaneously. I didn't see any messages, I was in X at that time. I also didn't find anything unusual in the system log, but /var did contain the following file after reboot and BG fsck finished: -r 1 rootwheel 2097152000 25 Feb 10:56 .dump_snapshot I repeated the same dump after the system was back up (after removing the snapshot), and all went well this time. Does this sound like a known problem? -- Regards, Georg. -- Georg-W. Koltermann <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [Fwd: mkisofs | burncd not working in 5.0 ?]
On Tue, 25 Feb 2003 02:48:31 +0100 David Vidal Rodríguez <[EMAIL PROTECTED]> wrote: > (forwarded from the NG comp.unix.bsd.freebsd.misc, from which I got no > answer) > > Hi! > > I'm somehow surprised that the following command pipe doesn't work any > more in 5.0R: > > $ mkisofs -J -r mydir | burncd -f /dev/acd1c -s 16 data - fixate Please try the patch in from the mail to -current with the Message-ID <[EMAIL PROTECTED]> and report if it works for you. Bye, Alexander. -- Reboot America. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
vm related panic
Hi, I occasionaly get this panic on my notebook, mostly at startup. I don't know for sure when it started, but it certainly didn't panic back in january/early february. FreeBSD fangorn.middleearth 5.0-CURRENT FreeBSD 5.0-CURRENT #6: Mon Feb 24 15:44:00 CET 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/FANGORN i386 Fatal trap 12: page fault while in kernel mode fault virtual address = 0x72 fault code = supervisor read, page not present instruction pointer = 0x8:0xc02311c7 stack pointer = 0x10:0xcdc60958 frame pointer = 0x10:0xcdc60970 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 = 68 (sysctl) kernel: type 12 trap, code=0 Stopped at vm_object_pip_add+0x37: movzwl 0x72(%esi),%eax db> tr vm_object_pip_add(0,1,1,cdc60a28,cdc60a18) at vm_object_pip_add+0x37 vm_fault(c082f000,c0757000,1,0,c257f960) at vm_fault+0x2b0 trap_pfault(cdc60b14,0,c0757a1d,1,c0757a1d) at trap+0x3cd trap(c0450018,10,cdc60010,c0eb6000,cdc60c0c) at trap+0x3cd calltrap() at calltrap+0x5 --- trap 0xc, eip = 0xc02aec98, esp = 0xcdc60b54, ebp = 0xcdc60b54 --- strlen(c0757a1d,c04f36b1,12,c04a8068,20e9) at strlen+0x8 sysctl_kern_function_list_iterate(c0757a1d,cdc60c0c,c0e90048,c0eb6000,c0eb6000) at sysctl_kern_function_l ist_iterate+0x1a link_elf_each_function_name(c0eb6000,c02315f0,cdc60c0c,707,cdc60c0c) at link_elf_each_function_name+0x45 sysctl_kern_function_list(c0405a00,0,0,cdc60c0c,cdc60c0c) at sysctl_kern_function_list+0xec sysctl_root(0,cdc60ca8,2,cdc60c0c,bfbff40c) at sysctl_root+0x15b userland_sysctl(c257f960,cdc60ca8,2,0,bfbff40c) at userland_sysctl+0x1c2 __sysctl(c257f960,cdc60d10,c03d2d3e,407,6) at __sysctl+0xb0 syscall(2f,2f,2f,4,805befd) at syscall+0x28e Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (202, FreeBSD ELF32, __sysctl), eip = 0x805ae27, esp = 0xbfbff3bc, ebp = 0xbfbffc68 --- db> - Christian -- Christian Brueffer [EMAIL PROTECTED] [EMAIL PROTECTED] GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D pgp0.pgp Description: PGP signature
Re: Witness This
No bugs so far with this.
Robert Watson wrote:
Revised patch without typo attached.
Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
[EMAIL PROTECTED] Network Associates Laboratories
Index: tcp_subr.c
===
RCS file: /data/fbsd-cvs/ncvs/src/sys/netinet/tcp_subr.c,v
retrieving revision 1.155
diff -u -r1.155 tcp_subr.c
--- tcp_subr.c 21 Feb 2003 23:17:12 - 1.155
+++ tcp_subr.c 22 Feb 2003 02:44:42 -
@@ -484,7 +484,7 @@
m->m_pkthdr.len = tlen;
m->m_pkthdr.rcvif = (struct ifnet *) 0;
#ifdef MAC
- if (tp != NULL) {
+ if (tp != NULL && tp->t_inpcb != NULL) {
/*
* Packet is associated with a socket, so allow the
* label of the response to reflect the socket label.
--
Daniel C. Sobral (8-DCS)
Gerencia de Operacoes
Divisao de Comunicacao de Dados
Coordenacao de Seguranca
TCO
Fones: 55-61-313-7654/Cel: 55-61-9618-0904
E-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Outros:
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
I disagree with what you say, but will defend
to the death your right to tell such LIES!
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
[CURRENT] Two panics in 15mn bp not locked
Hi,
Just got two panics after upgrading yesterday (to fix the sound card
problem). The second one happened during the bg fsck of the first panic
(dunno if it is related).
FreeBSD 5.0-CURRENT #8: Mon Feb 24 15:21:31 CET 2003
[EMAIL PROTECTED]:/src/src/sys/i386/compile/tCAERDONN
panic: bremfree: bp 0xc77d3cf0 not locked
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0xc3b05000
fault code = supervisor write, page not present
instruction pointer = 0x8:0xc02a6897
stack pointer = 0x10:0xcd2f4bf0
frame pointer = 0x10:0xcd2f4c34
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 = 21 (irq9: pcm0 acpi0)
trap number = 12
panic: page fault
(kgdb) where
#0 doadump () at ../../../kern/kern_shutdown.c:239
#1 0xc019d6a5 in boot (howto=260) at ../../../kern/kern_shutdown.c:371
#2 0xc019d8e3 in panic () at ../../../kern/kern_shutdown.c:542
#3 0xc01d7c47 in bremfreel (bp=0xc02d9d6d) at ../../../kern/vfs_bio.c:672
#4 0xc01d7bb5 in bremfree (bp=0x0) at ../../../kern/vfs_bio.c:659
#5 0xc01d9cdb in vfs_bio_awrite (bp=0xc0ec53c0)
at ../../../kern/vfs_bio.c:1714
#6 0xc01e0def in vop_stdfsync (ap=0xcd2f4a18)
at ../../../kern/vfs_default.c:755
#7 0xc016ad40 in spec_fsync (ap=0xcd2f4a18)
at ../../../fs/specfs/spec_vnops.c:422
#8 0xc016a2f8 in spec_vnoperate (ap=0x0)
at ../../../fs/specfs/spec_vnops.c:123
#9 0xc02513a7 in ffs_sync (mp=0xc25a5200, waitfor=2, cred=0xc0eb5e80,
td=0xc02fa620) at vnode_if.h:612
#10 0xc01eca6b in sync (td=0xc02fa620, uap=0x0)
at ../../../kern/vfs_syscalls.c:138
#11 0xc019d2f2 in boot (howto=256) at ../../../kern/kern_shutdown.c:280
#12 0xc019d8e3 in panic () at ../../../kern/kern_shutdown.c:542
#13 0xc02a8590 in trap_fatal (frame=0xc0ec53c0, eva=0)
at ../../../i386/i386/trap.c:844
#14 0xc02a82a2 in trap_pfault (frame=0xcd2f4bb0, usermode=0, eva=3283111936)
at ../../../i386/i386/trap.c:758
#15 0xc02a7e6d in trap (frame=
{tf_fs = -1033306088, tf_es = -1069613040, tf_ds = -1016070128, tf_edi =
-1011855360, tf_esi = -1034071296, tf_ebp = -852538316, tf_isp = -852538404, tf_ebx =
-1034047488, tf_edx = -1033486336, tf_ecx = 1024, tf_eax = 0, tf_trapno = 12, tf_err =
2, tf_eip = -1070962537, tf_cs = 8, tf_eflags = 66054, tf_esp = -1033400832, tf_ss =
-1069561263}) at ../../../i386/i386/trap.c:445
#16 0xc02992c8 in calltrap () at {standard input}:96
#17 0xc03f56a5 in ?? ()
#18 0xc03f5a97 in ?? ()
#19 0xc03f5ae3 in ?? ()
#20 0xc03f5ec5 in ?? ()
#21 0xc03e8cdf in ?? ()
#22 0xc018b602 in ithread_loop (arg=0xc25b3400)
at ../../../kern/kern_intr.c:536
#23 0xc018a6d4 in fork_exit (callout=0xc25db000, arg=0x0, frame=0x0)
at ../../../kern/kern_fork.c:871
Second trace:
syncing disks, buffers remaining... panic: bremfree: bp 0xc78625b8 not locked
Uptime: 7m15s
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] [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[CTRL-C to abort] [CTRL-C to abort]
[CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to
abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] 32 48
64 80 96 112 128 144 160 176 192 208 224 240
---
#0 doadump () at ../../../kern/kern_shutdown.c:239
239 dumping++;
(kgdb) where
#0 doadump () at ../../../kern/kern_shutdown.c:239
#1 0xc019d6a5 in boot (howto=260) at ../../../kern/kern_shutdown.c:371
#2 0xc019d8e3 in panic () at ../../../kern/kern_shutdown.c:542
#3 0xc01d7c47 in bremfreel (bp=0xc02d9d6d) at ../../../kern/vfs_bio.c:672
#4 0xc01d7bb5 in bremfree (bp=0x0) at ../../../kern/vfs_bio.c:659
#5 0xc01d9cdb in vfs_bio_awrite (bp=0xc264f000)
at ../../../kern/vfs_bio.c:1714
#6 0xc01e0def in vop_stdfsync (ap=0xcdd8eaf4)
at ../../../kern/vfs_default.c:755
#7 0xc016ad40 in spec_fsync (ap=0xcdd8eaf4)
at ../../../fs/specfs/spec_vnops.c:422
#8 0xc016a2f8 in spec_vnoperate (ap=0x0)
at ../../../fs/specfs/spec_vnops.c:123
#9 0xc02513a7 in ffs_sync (mp=0xc25a5200, waitfor=2, cred=0xc0eb5e80,
td=0xc02fa620) at vnode_if.h:612
#10 0xc01eca6b in sync (td=0xc02fa620, uap=0x0)
at ../../../kern/vfs_syscalls.c:138
#11 0xc019d2f2 in boot (howto=256) at ../../../kern/kern_shutdown.c:280
#12 0xc019d8e3 in panic () at ../../../kern/kern_shutdown.c:542
#13 0xc027895d in mtrash_ctor (mem=0xc264f000, size=0, arg=0x0)
at ../../../vm/uma_dbg.c:138
#14 0xc0278a00 in mtrash_fini (mem=0x0, size=0) at ../../../vm/uma_dbg.c:189
#15 0xc02762a9 in zone_drain (zone=0x100) at ../../../vm/uma_core.c:630
#16 0xc0276ee5 in zone_foreach (zfunc=0xc0276070 )
at ../../../vm/uma_core.c:1166
#17 0xc0278277 in uma_reclaim () at .
Followup [Re: tired of crashes]
On Wed, Feb 05, 2003 at 11:47:44AM +0200, Vallo Kallaste wrote:
> In the last ~three months now I've had 24 kernel crashes, all the
> same, all happening in the same circumstances. Happens while cvsup
> is running, everytime... except if I remove the checkouts file which
> probably causes slowdown of cvsup operation. I have recreated the
> filesystem on /dev/da2s1e several times anew, to exclude any
> accumulated filesystem corruption. This is on UFS2 filesystem,
> haven't tried UFS1 yet. World and kernel are from January 21, PIII
> SMP system. I'll provide any info one needs to track the cause,
> needless to say I'm _really_ tired of it.
When I updated to Feb 5 world/kernel (after the crashes in a row for
several months), I did extensive testing and found the crash gone.
The test procedure did incremental cvsup over the time range of
01.01.2002 - 30.12.2002 in steps of 1 day. It took quite a while
(day or so) and generated astonishing amount of I/O on the
problematic disk/filesystem. I ran the test for two times, to be
sure, with XFree and usual apps/activity running and without. No
crash. But it's still there, today I got one and it happens
_exactly_ on the same conditions. Got to work in the morning, did
startx (no xdm) and KDE started up, fired up several ssh sessions
and read my mail with mutt, then started cvsup to catch up the
"bleeding edge". While cvsup running, switched to free workspace in
KDE and started up Phoenix, to read Daemonnews... at the very moment
the Phoenix window appeared on the screen, the system crashed.
For now I quess it's somehow related to XFree/Phoenix/cvsup combo,
because I remember the last ten (or so) crashes quite well and I
_was starting or starting to use_ Phoenix the times the crash
happened (and cvsup running as well). Can it be related to mga.ko
module or somesuch? I don't do any DRI or 3D myself, but perhaps
Phoenix does something behind the scenes? Just wild guess.
Script started on Tue Feb 25 11:15:39 2003
bash-2.05b# gdb -k /sys/i386/compile/Myhakas-5.0-SMP-4BSD/kernel.debug /usr/cra
sh/vmcore.25
GNU gdb 5.2.1 (FreeBSD)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-undermydesk-freebsd"...
panic: bwrite: buffer is not busy???
panic messages:
---
panic: ufs_dirbad: bad dir
cpuid = 1; lapic.id = 0100
boot() called on cpu#1
syncing disks, buffers remaining... panic: bwrite: buffer is not busy???
cpuid = 1; lapic.id = 0100
boot() called on cpu#1
Uptime: 18d19h30m18s
Dumping 511 MB
16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368
384 400 416 432 448 464 480 496
---
#0 doadump () at ../../../kern/kern_shutdown.c:232
warning: Source file is more recent than executable.
232 }
(kgdb) where
#0 doadump () at ../../../kern/kern_shutdown.c:232
#1 0xc024096a in boot (howto=260) at ../../../kern/kern_shutdown.c:364
#2 0xc0240c37 in panic () at ../../../kern/kern_shutdown.c:531
#3 0xc02883c2 in bwrite (bp=0xce6d2b68) at ../../../kern/vfs_bio.c:798
#4 0xc0289b66 in vfs_bio_awrite (bp=0xce6d2b68)
at ../../../kern/vfs_bio.c:1650
#5 0xc0204903 in spec_fsync (ap=0xe3a4f804)
at ../../../fs/specfs/spec_vnops.c:459
#6 0xc0203c48 in spec_vnoperate (ap=0x0)
at ../../../fs/specfs/spec_vnops.c:123
#7 0xc035248b in ffs_sync (mp=0xc41c7a00, waitfor=2, cred=0xc1514e80,
td=0xc0444a20) at vnode_if.h:612
#8 0xc029e2fb in sync (td=0xc0444a20, uap=0x0)
at ../../../kern/vfs_syscalls.c:138
#9 0xc024054b in boot (howto=256) at ../../../kern/kern_shutdown.c:273
#10 0xc0240c37 in panic () at ../../../kern/kern_shutdown.c:531
#11 0xc035a442 in ufs_dirbad (ip=0x0, offset=0, how=0x0)
at ../../../ufs/ufs/ufs_lookup.c:631
#12 0xc0359967 in ufs_lookup (ap=0xe3a4faa4)
at ../../../ufs/ufs/ufs_lookup.c:294
#13 0xc03612a8 in ufs_vnoperate (ap=0x0) at ../../../ufs/ufs/ufs_vnops.c:2787
#14 0xc028df1c in vfs_cache_lookup (ap=0x0) at vnode_if.h:82
#15 0xc03612a8 in ufs_vnoperate (ap=0x0) at ../../../ufs/ufs/ufs_vnops.c:2787
#16 0xc0292732 in lookup (ndp=0xe3a4fc18) at vnode_if.h:52
#17 0xc029213b in namei (ndp=0xe3a4fc18) at ../../../kern/vfs_lookup.c:181
#18 0xc02a1362 in lstat (td=0xc5c5fb60, uap=0xe3a4fd10)
at ../../../kern/vfs_syscalls.c:1700
#19 0xc03c4c6c in syscall (frame=
{tf_fs = 136118319, tf_es = 134873135, tf_ds = 136118319, tf_edi =
1361343---Type to continue, or q to quit---
04, tf_esi = 134876320, tf_ebp = 136133492, tf_isp = -475726476, tf_ebx = 136631584,
tf_edx = 0, tf_ecx = 0, tf_eax = 190, tf_trapno = 22, tf_err = 2, tf_eip = 672677171,
tf_cs = 31, tf_eflags = 582, tf_esp = 136133356, tf_ss = 47})
at ../../../i386/i386/trap.c:1033
#20 0xc03acacd in Xint0x80_syscall () at {standard
Re: =?x-unknown?q?Re=3A_Diskless_b=F8rked?=
This patch worked.
On Tue, 25 Feb 2003, Jeff Roberson wrote:
> Please try this:
> Index: nfs_vnops.c
> ===
> RCS file: /home/ncvs/src/sys/nfsclient/nfs_vnops.c,v
> retrieving revision 1.195
> diff -u -r1.195 nfs_vnops.c
> --- nfs_vnops.c 25 Feb 2003 03:37:47 - 1.195
> +++ nfs_vnops.c 25 Feb 2003 08:31:54 -
> @@ -2812,9 +2812,9 @@
> panic("nfs_fsync: not dirty");
> if ((passone || !commit) && (bp->b_flags & B_NEEDCOMMIT))
> {
> BUF_UNLOCK(bp);
> - VI_LOCK(vp);
> continue;
> }
> + VI_UNLOCK(vp);
> bremfree(bp);
> if (passone || !commit)
> bp->b_flags |= B_ASYNC;
>
>
> On Tue, 25 Feb 2003, Poul-Henning Kamp wrote:
>
> >
> > recursed on non-recursive lock (sleep mutex) vnode interlock @ ../../../kern/vfs
> > _subr.c:1897
> > first acquired @ ../../../nfsclient/nfs_vnops.c:2786
> > panic: recurse
> > Debugger("panic")
> > Stopped at 0xc0405cde = Debugger+0x7e: xchgl %ebx,0xc05aece0 = in_Deb
> > ugger.0
> > db> trace
> > Debugger(c0466931,c04ff7e0,c0469426,d7aad8f8,1) at 0xc0405cde = Debugger+0x7e
> > panic(c0469426,c0470d18,ae2,c046d74d,769) at 0xc022cd7d = panic+0x11d
> > witness_lock(c418eb68,8,c046d74d,769,269) at 0xc0263853 = witness_lock+0x643
> > _mtx_lock_flags(c418eb68,0,c046d74d,769,ce537610) at 0xc021ca1a = _mtx_lock_flag
> > s+0x11a
> > reassignbuf(ce537610,c418eb68,269,ce537610,ce537610) at 0xc02b7154 = reassignbuf
> > +0xa4
> > bundirty(ce537610,29c,d7aad9d0,c021cb22,c053d260) at 0xc029b185 = bundirty+0x85
> > nfs_writebp(ce537610,1,c3f67c30,29c,d7aadaa0) at 0xc032e30d = nfs_writebp+0x9d
> > nfs_bwrite(ce537610,12,0,ae2,c02652be) at 0xc0314631 = nfs_bwrite+0x31
> > nfs_flush(c418eb68,c14fd280,1,c3f67c30,1) at 0xc032ddf3 = nfs_flush+0xb13
> > nfs_fsync(d7aadb04,0,c046d74d,460,264) at 0xc032d2bf = nfs_fsync+0x3f
> > vinvalbuf(c418eb68,1,c14fd280,c3f67c30,0) at 0xc02b48bf = vinvalbuf+0x16f
> > nfs_vinvalbuf(c418eb68,1,c14fd280,c3f67c30,1) at 0xc0317af5 = nfs_vinvalbuf+0x25
> > 5
> > nfs_close(d7aadb94,c0482180,c418eb68,a,c14fd280) at 0xc0324090 = nfs_close+0xe0
> > vn_close(c418eb68,a,c14fd280,c3f67c30,d7aadc34) at 0xc02c8695 = vn_close+0x65
> > vn_closefile(c415b528,c3f67c30,c046412c,765,0) at 0xc02c9d9e = vn_closefile+0x3e
> > fdrop_locked(c415b528,c3f67c30,c046412c,69f,4002) at 0xc01ff7cc = fdrop_locked+0
> > x1fc
> > fdrop(c415b528,c3f67c30,c413de34,0,4002) at 0xc01ff00a = fdrop+0x5a
> > closef(c415b528,c3f67c30,c046412c,350,c415b528) at 0xc01fef8c = closef+0x1bc
> > close(c3f67c30,d7aadd10,c047a999,407,1) at 0xc01fc73e = close+0x21e
> > syscall(2f,2f,2f,0,0) at 0xc0422c0e = syscall+0x45e
> > Xint0x80_syscall() at 0xc04084ad = Xint0x80_syscall+0x1d
> > --- syscall (6, FreeBSD ELF32, close), eip = 0x804afdb, esp = 0xbfbff81c, ebp =
> > 0xbfbff828 ---
> > db>
> >
> > --
> > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
> > [EMAIL PROTECTED] | TCP/IP since RFC 956
> > FreeBSD committer | BSD since 4.3-tahoe
> > Never attribute to malice what can adequately be explained by incompetence.
> >
> > To Unsubscribe: send mail to [EMAIL PROTECTED]
> > with "unsubscribe freebsd-current" in the body of the message
> >
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: netncp/nwfs is rotting...
On Tue, Feb 25, 2003 at 02:33:19PM +0600, Max Khon wrote: > I have a patch that makes nwfs work to some extent (i.e. I was able > to mount and use netware shares from mars_nwe server). Great. Care I have a copy of it? I've got it to the stage where it will say "Connection refused" when trying to mount a volume off a machine that isn't running any netware server software, and am in the middle of trying to figure out how to set up mars_nwe... Tim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
=?x-unknown?q?Re=3A_Diskless_b=F8rked?=
Please try this:
Index: nfs_vnops.c
===
RCS file: /home/ncvs/src/sys/nfsclient/nfs_vnops.c,v
retrieving revision 1.195
diff -u -r1.195 nfs_vnops.c
--- nfs_vnops.c 25 Feb 2003 03:37:47 - 1.195
+++ nfs_vnops.c 25 Feb 2003 08:31:54 -
@@ -2812,9 +2812,9 @@
panic("nfs_fsync: not dirty");
if ((passone || !commit) && (bp->b_flags & B_NEEDCOMMIT))
{
BUF_UNLOCK(bp);
- VI_LOCK(vp);
continue;
}
+ VI_UNLOCK(vp);
bremfree(bp);
if (passone || !commit)
bp->b_flags |= B_ASYNC;
On Tue, 25 Feb 2003, Poul-Henning Kamp wrote:
>
> recursed on non-recursive lock (sleep mutex) vnode interlock @ ../../../kern/vfs
> _subr.c:1897
> first acquired @ ../../../nfsclient/nfs_vnops.c:2786
> panic: recurse
> Debugger("panic")
> Stopped at 0xc0405cde = Debugger+0x7e: xchgl %ebx,0xc05aece0 = in_Deb
> ugger.0
> db> trace
> Debugger(c0466931,c04ff7e0,c0469426,d7aad8f8,1) at 0xc0405cde = Debugger+0x7e
> panic(c0469426,c0470d18,ae2,c046d74d,769) at 0xc022cd7d = panic+0x11d
> witness_lock(c418eb68,8,c046d74d,769,269) at 0xc0263853 = witness_lock+0x643
> _mtx_lock_flags(c418eb68,0,c046d74d,769,ce537610) at 0xc021ca1a = _mtx_lock_flag
> s+0x11a
> reassignbuf(ce537610,c418eb68,269,ce537610,ce537610) at 0xc02b7154 = reassignbuf
> +0xa4
> bundirty(ce537610,29c,d7aad9d0,c021cb22,c053d260) at 0xc029b185 = bundirty+0x85
> nfs_writebp(ce537610,1,c3f67c30,29c,d7aadaa0) at 0xc032e30d = nfs_writebp+0x9d
> nfs_bwrite(ce537610,12,0,ae2,c02652be) at 0xc0314631 = nfs_bwrite+0x31
> nfs_flush(c418eb68,c14fd280,1,c3f67c30,1) at 0xc032ddf3 = nfs_flush+0xb13
> nfs_fsync(d7aadb04,0,c046d74d,460,264) at 0xc032d2bf = nfs_fsync+0x3f
> vinvalbuf(c418eb68,1,c14fd280,c3f67c30,0) at 0xc02b48bf = vinvalbuf+0x16f
> nfs_vinvalbuf(c418eb68,1,c14fd280,c3f67c30,1) at 0xc0317af5 = nfs_vinvalbuf+0x25
> 5
> nfs_close(d7aadb94,c0482180,c418eb68,a,c14fd280) at 0xc0324090 = nfs_close+0xe0
> vn_close(c418eb68,a,c14fd280,c3f67c30,d7aadc34) at 0xc02c8695 = vn_close+0x65
> vn_closefile(c415b528,c3f67c30,c046412c,765,0) at 0xc02c9d9e = vn_closefile+0x3e
> fdrop_locked(c415b528,c3f67c30,c046412c,69f,4002) at 0xc01ff7cc = fdrop_locked+0
> x1fc
> fdrop(c415b528,c3f67c30,c413de34,0,4002) at 0xc01ff00a = fdrop+0x5a
> closef(c415b528,c3f67c30,c046412c,350,c415b528) at 0xc01fef8c = closef+0x1bc
> close(c3f67c30,d7aadd10,c047a999,407,1) at 0xc01fc73e = close+0x21e
> syscall(2f,2f,2f,0,0) at 0xc0422c0e = syscall+0x45e
> Xint0x80_syscall() at 0xc04084ad = Xint0x80_syscall+0x1d
> --- syscall (6, FreeBSD ELF32, close), eip = 0x804afdb, esp = 0xbfbff81c, ebp =
> 0xbfbff828 ---
> db>
>
> --
> Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
> [EMAIL PROTECTED] | TCP/IP since RFC 956
> FreeBSD committer | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: netncp/nwfs is rotting...
hi, there! On Mon, Feb 24, 2003 at 10:20:28PM -0800, Tim J. Robbins wrote: j > A few months ago there was a thread on this list discussing the state > of NWFS/netncp/libncp/etc. on 5.0. Terry Lambert produced a patch [1] > that made netncp compile. The patch still applies cleanly to -current > and almost compiles; I broke it with ncp_ncp.c rev 1.13, adding > #includes of sys/lock.h and sys/mutex.h fixes it. > > However, even with this patch, ncp.ko still does not load because the > aout_sysvec symbol is not available. After patching ncp_load() to use > SYS_MAXSYSCALL instead of elf_sysvec.sv_size, the module loads but > crashes in ncp_timer(): > > ncp_load: [210-213] > > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x10 > fault code = supervisor read, page not present > instruction pointer = 0x8:0xc1027d39 > stack pointer = 0x10:0xc5b9cc8c > frame pointer = 0x10:0xc5b9cc9c > code segment= base 0x0, limit 0xf, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags= interrupt enabled, IOPL = 0 > current process = 12 (swi6: clock) > > > Even after that has been fixed, there are plenty of other bug fixes that > need to be backported from smbfs. > > Is anyone still working on updating netncp/nwfs for 5.0? I think that it > should be retired to the Attic if nobody has any plans to fix it before > we create the RELENG_5 branch. I have a patch that makes nwfs work to some extent (i.e. I was able to mount and use netware shares from mars_nwe server). /fjoe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Diskless børked
recursed on non-recursive lock (sleep mutex) vnode interlock @ ../../../kern/vfs
_subr.c:1897
first acquired @ ../../../nfsclient/nfs_vnops.c:2786
panic: recurse
Debugger("panic")
Stopped at 0xc0405cde = Debugger+0x7e: xchgl %ebx,0xc05aece0 = in_Deb
ugger.0
db> trace
Debugger(c0466931,c04ff7e0,c0469426,d7aad8f8,1) at 0xc0405cde = Debugger+0x7e
panic(c0469426,c0470d18,ae2,c046d74d,769) at 0xc022cd7d = panic+0x11d
witness_lock(c418eb68,8,c046d74d,769,269) at 0xc0263853 = witness_lock+0x643
_mtx_lock_flags(c418eb68,0,c046d74d,769,ce537610) at 0xc021ca1a = _mtx_lock_flag
s+0x11a
reassignbuf(ce537610,c418eb68,269,ce537610,ce537610) at 0xc02b7154 = reassignbuf
+0xa4
bundirty(ce537610,29c,d7aad9d0,c021cb22,c053d260) at 0xc029b185 = bundirty+0x85
nfs_writebp(ce537610,1,c3f67c30,29c,d7aadaa0) at 0xc032e30d = nfs_writebp+0x9d
nfs_bwrite(ce537610,12,0,ae2,c02652be) at 0xc0314631 = nfs_bwrite+0x31
nfs_flush(c418eb68,c14fd280,1,c3f67c30,1) at 0xc032ddf3 = nfs_flush+0xb13
nfs_fsync(d7aadb04,0,c046d74d,460,264) at 0xc032d2bf = nfs_fsync+0x3f
vinvalbuf(c418eb68,1,c14fd280,c3f67c30,0) at 0xc02b48bf = vinvalbuf+0x16f
nfs_vinvalbuf(c418eb68,1,c14fd280,c3f67c30,1) at 0xc0317af5 = nfs_vinvalbuf+0x25
5
nfs_close(d7aadb94,c0482180,c418eb68,a,c14fd280) at 0xc0324090 = nfs_close+0xe0
vn_close(c418eb68,a,c14fd280,c3f67c30,d7aadc34) at 0xc02c8695 = vn_close+0x65
vn_closefile(c415b528,c3f67c30,c046412c,765,0) at 0xc02c9d9e = vn_closefile+0x3e
fdrop_locked(c415b528,c3f67c30,c046412c,69f,4002) at 0xc01ff7cc = fdrop_locked+0
x1fc
fdrop(c415b528,c3f67c30,c413de34,0,4002) at 0xc01ff00a = fdrop+0x5a
closef(c415b528,c3f67c30,c046412c,350,c415b528) at 0xc01fef8c = closef+0x1bc
close(c3f67c30,d7aadd10,c047a999,407,1) at 0xc01fc73e = close+0x21e
syscall(2f,2f,2f,0,0) at 0xc0422c0e = syscall+0x45e
Xint0x80_syscall() at 0xc04084ad = Xint0x80_syscall+0x1d
--- syscall (6, FreeBSD ELF32, close), eip = 0x804afdb, esp = 0xbfbff81c, ebp =
0xbfbff828 ---
db>
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: sh: turning off NDELAY mode
On Mon, Feb 24, 2003 at 12:20:05PM -0600, Dan Nelson wrote: > In the last episode (Feb 24), Christoph P. Kukulies said: > > On Mon, Feb 24, 2003 at 10:27:22AM -0600, Dan Nelson wrote: > > > In the last episode (Feb 24), Christoph Kukulies said: > > > > > > > > sh: turning off NDELAY mode > > > > > > > > appears from time to time in an xterm n my notebook > > > > running 5.0-current > > > > > > That means a program you were running exited without unsetting > > > non-blocking mode, so /bin/sh fixed it for you. > > > > OK, that's /usr/X11R6/bin/mozilla. > > Weird. That shouldn't be messing with the tty at all. Mozilla in its various builds uses tty heavily for lots of debug messages and logging. The version I was using - 1.0 I believe - writes this ominous 'no running window' out to the tty at startup. This message btw, isn't a bug, it's a feature I found out. It just says that not another instance of mozilla is running. But I'm drifting away. -- Chris Christoph P. U. Kukulies [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
