Re: boot hang: "ata1: resetting devices .. done" (5.1-CURRENT, IBM T30)
Quoting Dan Nelson <[EMAIL PROTECTED]>: > In the last episode (Oct 08), Robert Ferguson said: > > I see this problem as well. I'm running on a T40, with a DVD/CDRW in > > the ultrabay, and -CURRENT as of this morning. At boot, it hangs > > immediately after > > > > ad0: 35174MB [71465/16/63] at ata0-master UDMA100 > > ata1: resetting devices .. > > done > > > > Backing out the most recent checkin to sys/dev/ata/ata-queue.c (i.e. > > reverting to version 1.6) makes the problem go away. > > I upgraded from an Oct 1 -> Oct 12 kernel and saw the same hang. > Backing out r1.6 fixed it for me too. > "me too" Ken ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ipnat memory leak?
Quoting Vector <[EMAIL PROTECTED]>: > Several reasons: > > Having it in the kernel improves performance It also avoids at least 2 context switches per packet... one when the packet goes into natd and one when it goes back to the kernel. > > natd chokes on the latest windoze worms and I have implemented some DoS > prevention/worm protection in ipnat but I'm seeing this memory leak without > my improvements there at all. > > If it's in the kernel, ipnat is kept under control when natd would normally > be sucking the CPU dry and preventing things like remote logins, very > slugish updates, etc... > > and others I don't particularly want to go into at the moment. > > vec > Not to mention the syntax for doing things like stateful firewalling is much more sane, and the fact that you can view the firewall state-table in near real-time using ipfstat -t (top style viewing). Ken ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 2 ports broken after gcc import
> Alright, it had nothing to do with ACL's. Unknown to me, someone got on > that machine and enabled the firewall, and added rules. Those rules were > causing the problem (I'm not sure why he added a firewall on a machine > already behind one on a 192.168.0.0/24 network). Anyway, sorry for > wasting peoples' time, I should've checked that first. I figured out exactly which line caused this problem too, he added "flags S" to the rule that allowed outgoing traffic, causing only the syn to be allowed through the firewall, but breaking several other things, and he did it at around the same time as the gcc import. Anyway, lesson learned. Thanks for help whoever gave it. Ken ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 2 ports broken after gcc import
> Bizarre. I use ACLs in my kernel daily, and I use nmap almost daily, > and haven't seen this. If you re-add ACLs with a fresh kernel build, > does the problem come back? Could you look at ktraces of nmap with and > without ACLs and see what causes it? Do you have ACLs enabled on any > file systems, or are you just running with the kernel option? Alright, it had nothing to do with ACL's. Unknown to me, someone got on that machine and enabled the firewall, and added rules. Those rules were causing the problem (I'm not sure why he added a firewall on a machine already behind one on a 192.168.0.0/24 network). Anyway, sorry for wasting peoples' time, I should've checked that first. Ken ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: more hints
> If I remove "device pmtimer" from my config, I get a consistent panic, > or variation of: > > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x0 > fault code = supervisor read, page not present > instruction pointer = 0x8:0xc0135b0a7 > stack pointer = 0x10:0xd68f2c48 > frame pointer = 0x10:0xd68f2c64 > code segment = base 0x0 limit 0x, type 0x1b > processor eflags= interrupt enabled, resume, IOPL=0 > current process = 12 (swi7: tty:sio clock) > trap number = 12 > panic page fault > > ... > > > This is with leaving my USB 2.0 drive turned on during boot time. If > I use the same kernel (sans pmtimer) , but boot with my USB drive turned > off, all is well. Or, I can put pmtimer back in the kernel and boot > with the drive turned on, but sooner or later I'll get some type of > panic. Some kind of timimg issue?. > > I think all of these panics have something to do with leaving the USB > drive on at boot time. It seems like I don't have any issues if it > stays turned off. That's probably why we're not seeing any reports, I > doubt a lot of folks are using a USB 2.0 HD along with ehci... > > Again, all this started shortly after July 14th. The USB DMA changes > may have something to do with this... > I'll have time tomorrow to look at the commit logs, so I'll check out what changes went in, then make patches for each one that is likely to be a problem, and then submit them to you. That will allow you to pinpoint the exact commit that caused the problem. Ken ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 2 ports broken after gcc import
> I think I missed the message that this is a response to, but here's an > answer to the question: UFS_ACL controls only the introduction of ACL > code into UFS1 and UFS2 file systems, and enables conditional use of > ACLs code if the ACLs flag is set on a file system. If the ACLs flag is > not set on a file system, the UFS1/UFS2 code is intended to run along > its original permissions-based code path. Devfs isn't based on UFS, and > so it should be unaffected by the UFS_ACL flag. If there's a definite > causal relationship between UFS_ACL and the nmap failure, I can't help > but wonder if it's a result of a timing, code layout, or memory > allocation change of some sort. I wouldn't rule out a bug in the ACL > code, but it seems somewhat unlikely as, without the ACLs flag set, the > code path in the UFS code should be minimally changed... > > The best path to track this down is to try to figure out for sure which > system call is failing, compare expected vs. wire network transmissions, > and see if we can reproduce this in a simpler test program. > > We've recently made some changes in how the permissions of new objects > are calculated using ACLs; they were made somewhat before the gcc > changes, I believe, but it might also be interesting to see test cases > from before both changes, in between the changes, and after both, to > confirm that it was definitely the gcc change that kicked off the > problem, rather than the UFS change. Finally, I'd like to know what, if > any, optimization flags you're using for the kernel compile... > Well, don't worry too much, I went back and checked the kernel config I used for the kernel that was having problems, and it did indeed have IPFILTER compiled in, BUT I had no rules loading. Both of the rules files were empty. (That's basically what I said in my previous message). I just took me the better part of a night to sort out what I had on that box and remember what I did. Anyway, like I said, I won't be back on that box until Tuesday so I'll have to let you know which knob I turned then... although if it WAS the firewall that's really wierd since I had no rules loaded, and my other box that never had the problem DID have rules loaded. Ken ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 2 ports broken after gcc import
> I just built a fresh nmap on my -current box and it appears to work fine > for me, as did the older nmap. So I guess that leaves me firmly in the > "unable to reproduce" camp. I have noticed that, on my wi0 boxes, I > tend to get a fair number of ENOBUFS errors when nmaping, but that > appears to be unrelated to the presence of UFS_ACL in the kernel. > > Are your different boxes using the same type of network interface? Do > you rely on routed or use static routes? If you tcpdump the interface, > do any nmap packets get out -- for example, the initial ping it performs > before scanning a host, or none? Well, on one of my boxes, I have IPFILTER, but no ACL's and it works fine, on the one that was previously not working, I had IPFILTER (but with no rules set) and ACL's. I removed all references to ipfilter from rc.conf (my ipf.rules and ipnat.rules were blank), removed IPFILTER and ACL from the kernel, recompiled, and rebooted, and it started working. So now I just have to go back and figure out which knob I turned to fix things. I'm running late now though so I'll let you know as soon as I can get back to it (the computer that was really having the problems was at work, so I can't get to it until tuesday). Ken ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 2 ports broken after gcc import
> Might devfs propagate ACL characteristics via /dev nodes into > applications? Otherwise, the symptom you described would have made me > point to the IP firewall first. > My machine that was showing the problem didn't have a firewall enabled. I'll still mess with it some more to see what I can come up with, maybe it was the firewall, but I don't remember having ipfilter or ipfirewall in the kernel but it'd been a while since I edited that config file or compiled that kernel so maybe I took out the firewall options and never compiled, and then compiled today. (It's been about a month since I did anything kernel related on that machine). Anyway, when I pinpoint the problem I'll mail the list. Ken ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 2 ports broken after gcc import
> Bizarre. I use ACLs in my kernel daily, and I use nmap almost daily, > and haven't seen this. If you re-add ACLs with a fresh kernel build, > does the problem come back? Could you look at ktraces of nmap with and > without ACLs and see what causes it? Do you have ACLs enabled on any > file systems, or are you just running with the kernel option? I was running with just the kernel option, and nothing configured for it. I can't think of what else the problem could be, when I recompiled the kernel it just started working again, it might not have anything at all to do with ACL's and more to do with the fact that I just recompiled it. One of my other -CURRENT machines is working now as well after a recompile. I'll do more testing to see if I can pinpoint the problem and I'll probably have results by Tuesday (holiday weekend :-P ) Ken ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 2 ports broken after gcc import
> Just for more info, when was the last time you updated your /etc? on my > 4th -CURRENT machine, with the same compiler etc... I havn't updated my > /etc/ since June 1, and that machine works, the other 3 have been updated > very recently, like within the last few weeks, and they're all broken. So > I guess it's not a compiler issue, but some kind of configuration issue. I > can't think of what the problem could be though. > OK, checked over my kernel configurations and found that ACL's were in my kernel configuration. I took that option out and things are working again. I have no idea how ACL's could've caused what I was seeing, but everything is working now. Thanks for your help. Ken ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 2 ports broken after gcc import
Just for more info, when was the last time you updated your /etc? on my 4th -CURRENT machine, with the same compiler etc... I havn't updated my /etc/ since June 1, and that machine works, the other 3 have been updated very recently, like within the last few weeks, and they're all broken. So I guess it's not a compiler issue, but some kind of configuration issue. I can't think of what the problem could be though. Ken On Fri, 29 Aug 2003, Kenneth Culver wrote: > > [EMAIL PROTECTED] root]# uname -a > > FreeBSD tao.xtaz.co.uk 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Sun Aug 24 13:35:21 > > BST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/TAO i386 > > > > [EMAIL PROTECTED] root]# gcc -v > > Using built-in specs. > > Configured with: FreeBSD/i386 system compiler > > Thread model: posix > > gcc version 3.3.1 [FreeBSD] > > > > [EMAIL PROTECTED] root]# nmap -sS -O 192.168.1.10 > > > > Starting nmap 3.30 ( http://www.insecure.org/nmap/ ) at 2003-08-29 19:21 BST > > Interesting ports on neo.xtaz.co.uk (192.168.1.10): > > (The 1636 ports scanned but not shown below are in state: closed) > > Port State Service > > 21/tcp openftp > > 22/tcp openssh > > 23/tcp opentelnet > > 111/tcpopensunrpc > > 113/tcpopenauth > > 1023/tcp opennetvenuechat > > 2049/tcp opennfs > > 6000/tcp openX11 > > Device type: general purpose > > Running (JUST GUESSING) : FreeBSD 5.X|4.X|2.X|3.X (97%), Amiga AmigaOS (92%), > > IBM AIX 5.X (90%), Apple Mac OS X 10.1.X (90%), Novell Netware 3.X|4.X|5.X > > (89%) > > Aggressive OS guesses: FreeBSD 5.0-RELEASE (97%), FreeBSD 4.3 - 4.4-RELEASE > > (93%), FreeBSD 4.7-RELEASE (X86) (93%), FreeBSD 5.1-CURRENT (June 2003) on > > Sparc64 (93%), AmigaOS Miami Deluxe 0.9 - Miami 3.2B (92%), AmigaOS 3.5/3.9 > > running Miami Deluxe 1.0c (92%), FreeBSD 2.2.1 - 4.1 (92%), FreeBSD 4.4-STABLE > > (92%), FreeBSD 4.7-STABLE (92%), IBM AIX 5.1 (90%) > > No exact OS matches for host (test conditions non-ideal). > > > > Nmap run completed -- 1 IP address (1 host up) scanned in 31.448 seconds > > > > Seems ok to me? > > > > Incidently it probably can't guess the box is fbsd because I have tcp > > extensions turned off on it. > > > Did the same thing, portupgrade -f nmap, and then ran it with the same > flags, and I'm still getting the same problem. It's doing this on all 3 of > my FreeBSD-CURRENT machines as well. > > Ken > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 2 ports broken after gcc import
> [EMAIL PROTECTED] root]# uname -a > FreeBSD tao.xtaz.co.uk 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Sun Aug 24 13:35:21 > BST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/TAO i386 > > [EMAIL PROTECTED] root]# gcc -v > Using built-in specs. > Configured with: FreeBSD/i386 system compiler > Thread model: posix > gcc version 3.3.1 [FreeBSD] > > [EMAIL PROTECTED] root]# nmap -sS -O 192.168.1.10 > > Starting nmap 3.30 ( http://www.insecure.org/nmap/ ) at 2003-08-29 19:21 BST > Interesting ports on neo.xtaz.co.uk (192.168.1.10): > (The 1636 ports scanned but not shown below are in state: closed) > Port State Service > 21/tcp openftp > 22/tcp openssh > 23/tcp opentelnet > 111/tcpopensunrpc > 113/tcpopenauth > 1023/tcp opennetvenuechat > 2049/tcp opennfs > 6000/tcp openX11 > Device type: general purpose > Running (JUST GUESSING) : FreeBSD 5.X|4.X|2.X|3.X (97%), Amiga AmigaOS (92%), > IBM AIX 5.X (90%), Apple Mac OS X 10.1.X (90%), Novell Netware 3.X|4.X|5.X > (89%) > Aggressive OS guesses: FreeBSD 5.0-RELEASE (97%), FreeBSD 4.3 - 4.4-RELEASE > (93%), FreeBSD 4.7-RELEASE (X86) (93%), FreeBSD 5.1-CURRENT (June 2003) on > Sparc64 (93%), AmigaOS Miami Deluxe 0.9 - Miami 3.2B (92%), AmigaOS 3.5/3.9 > running Miami Deluxe 1.0c (92%), FreeBSD 2.2.1 - 4.1 (92%), FreeBSD 4.4-STABLE > (92%), FreeBSD 4.7-STABLE (92%), IBM AIX 5.1 (90%) > No exact OS matches for host (test conditions non-ideal). > > Nmap run completed -- 1 IP address (1 host up) scanned in 31.448 seconds > > Seems ok to me? > > Incidently it probably can't guess the box is fbsd because I have tcp > extensions turned off on it. > Did the same thing, portupgrade -f nmap, and then ran it with the same flags, and I'm still getting the same problem. It's doing this on all 3 of my FreeBSD-CURRENT machines as well. Ken ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
2 ports broken after gcc import
Hi, Since this is related to both -current and to ports I crossposted to both. Basically (I've asked this question before, with no answer), several network-related apps broke after the last gcc import. nmap no longer works: kaoru:~:# nmap -sS -O 66.92.171.91 Starting nmap 3.30 ( http://www.insecure.org/nmap/ ) at 2003-08-29 14:13 EDT sendto in send_tcp_raw: sendto(3, packet, 40, 0, 66.92.171.91, 16) => No route to host I know there is a route to that ip because I'm connected to it from my current machine right now. This behavior started after the import. Also, with smbclient: kaoru:~:# smbclient -L iscprt added interface ip=192.168.0.27 bcast=192.168.0.255 nmask=255.255.255.0 added interface ip=127.0.0.2 bcast=127.255.255.255 nmask=255.0.0.0 Packet send failed to 127.255.255.255(137) ERRNO=Can't assign requested address Connection to iscprt failed This also only started after the import. (or maybe there was another commit that day that caused this problem, I don't know). Anyway, the nmap problem is a big one since I have to scan several machines in my network with nessus, which relies on nmap to work, and I need smbclient/smbspool to print through cups to printers on the local windows network. Is anyone else seeing these problems? Is anyone working on fixes? Ken ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD / KDE locking up solid
> Evan Dower wrote: > > You say you have a GeForce 4? Do you have nvidia-driver installed? > > Nvidia-driver makes my computer lock up like the dickens. ;-) > Removing gl-support for kde should do fine. > > Hendrik > I have it working here fine with GL support and no hangs. Ken ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: atapicam panic at boot.
> free_hcb() > atapi_action() > xpt_run_dev_sendq() > xpt_action() > probe_start() > ... > I think some people are already tracking this down related to the recent update of the ata drivers. Ken ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: KDE Konsole, crashes, on a SIGABRT...
> see my post yesterday to -current or -ports with the 2 attachments. > > the KDE team found the bug, and fixed it. > > There are 2 patches to add to the port, which fix it. > Yeah, I just saw that, I was gone for the weeknend, sorry for the extra chatter. Ken ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: KDE Konsole, crashes, on a SIGABRT...
> I can't explain it. Someone is going to have to debug konsole and > figure out what is going on. I can concur, before last thursday, konsole worked fine with libc_r, but crashed randomly with libkse and libthr. After last thursday it even crashes with libc_r. Ken ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HTT on current
> Hi, > > I have a HTT capabale PCU on an Intel MB with the 875P chipset. I have > enabled HTT in the BIOS and compiled my kernel with the required SMP > options, however i dont think the system is really running in SMP mode. Top > does not display CPU numbers. Here is my dmesg: > > --- > > FreeBSD 5.1-CURRENT #0: Fri Aug 22 15:41:01 EDT 2003 > > CPU: Intel(R) Pentium(R) 4 CPU 2.40GHz (2394.01-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0xf29 Stepping = 9 > > Features=0xbfebfbff ,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> > Hyperthreading: 2 logical CPUs > real memory = 1072889856 (1023 MB) > avail memory = 1037774848 (989 MB) > Pentium Pro MTRR support enabled > npx0: on motherboard > npx0: INT 16 interface > acpi0: on motherboard > pcibios: BIOS version 2.10 > Using $PIR table, 12 entries at 0xc00f3310 > acpi0: power button is handled as a fixed feature programming model. > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 > acpi_cpu0: on acpi0 > acpi_cpu1: on acpi0 > > --- > Where's the rest of your dmesg? Ken ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: problem after gcc import
> Read freebsd-current. :-) A suggestion was given this week: > > Subject: Re: Vim: Caught deadly signal BUS (after -current update with new gcc) > Date: Wed, 16 Jul 2003 23:14:30 -0700 > To: "Karel J. Bosschaart" <[EMAIL PROTECTED]> > On Tue, Jul 15, 2003 at 11:07:40AM +0200, Karel J. Bosschaart wrote: > > FWIW, the new behaviour of vim is caused by patch 6.2.015. I added > > 015 to BADPATCHES in the ports Makefile and reinstalled. gvim works > > as usual now. > Ahh thanks, that'll teach me to let my "d"elete finger get away from me. :-P Ken ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
problem after gcc import
Hi, I followed all suggestions from /usr/src/UPDATING after the gcc 3.3.1 import, and rebuilt kernel and world after removing /usr/obj and /usr/src/sys/i386/compile/KAORU (my kernel config file's name). However, I'm seeing some strange behavior after that. 1) smbclient no longer works without specifying the -I flag: kaoru:~:> smbclient -L iscprt added interface ip=192.168.0.27 bcast=192.168.0.255 nmask=255.255.255.0 added interface ip=127.0.0.2 bcast=127.255.255.255 nmask=255.0.0.0 Packet send failed to 127.255.255.255(137) ERRNO=Can't assign requested address Connection to iscprt failed This didn't happen before the new gcc. Second: I use gvim as my editor-of-choice for programming in C, and now this happens: kaoru:~:> gvim Vim: Caught deadly signal BUS Vim: Finished. And when I backtrace it in gdb: kaoru:/usr/ports/editors/vim/work/vim62/src:# gdb ./vim 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"... (gdb) run Starting program: /usr/ports/editors/vim/work/vim62/src/vim Program received signal SIGBUS, Bus error. 0x28684fc6 in _IceConnectionOpened () from /usr/X11R6/lib/libICE.so.6 (gdb) bt #0 0x28684fc6 in _IceConnectionOpened () from /usr/X11R6/lib/libICE.so.6 #1 0x286797f6 in IceOpenConnection () from /usr/X11R6/lib/libICE.so.6 #2 0x2866f199 in SmcOpenConnection () from /usr/X11R6/lib/libSM.so.6 #3 0x080fceed in xsmp_init () at os_unix.c:5961 #4 0x080b90de in main (argc=0, argv=0xbfbffa60) at main.c:1180 #5 0x080650d2 in _start () It looks like it's dying somewhere in X's libICE. I'm not sure what that's used for, but when I rebuilt libICE with debugging symbols enabled, and traced through the code, there's a pointer in _IceConnectonOpened() that has the value 0xd0d0d0d0 which is causing the crash. This is a wierd crash because on my other 2 FreeBSD machines, (1 an Athlon XP 2000+, the other a dual PII 333) this doesn't happen. The PII doesn't have X though so I'm assuming that's why there's no problem there. The machine this is happening on is a P4. Maybe that's the issue? Anyway, I also turned off all optimizations (no -O or -mcpu=pentiumpro) and recompiled vim, the X11 Libraries, and samba, but the same problem still occurs. Any ideas? Ken ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: NVidia driver stability?
> I've been seeing this *exact* same behaviour on a Riva TNT2 for some > time now. I find the new driver to be a /little/ more stable -- i.e. > it's only locked up once on me since I installed it on Monday, as > opposed to locking up three out of the four mornings for the previous > driver. > > I /do/ use FreeBSD's AGP driver, as I found that otherwise I just had > massive instability problems. Back when I used the first nvidia driver with my old Geforce 3 TI 200, I didn't see anything like this, occasionally a FreeBSD app would cause a crash, but as long as I set the environment variable that kept things single threaded, I had no problems. This could be your problem: >From the README on nvidia's driver page for FreeBSD: The NVIDIA FreeBSD Accelerated Driver Set is fully thread-safe if native, multi-threaded applications are developed using the FreeBSD linux-threads port. If the above mentioned linux_sysvec.c.diff patch is applied, then the Linux ABI compatibility libraries are also fully thread-safe. The native NVIDIA FreeBSD OpenGL driver does not currently interact well with the libc_r, libkse, or libthr thread libraries. Until these issues are resolved, it is recommended that you use the FreeBSD linux-threads port for multithreaded OpenGL applications. I've seen problems on my friends machine until we compiled native GL apps to use linuxthreads, and set the appropriate environment variables before running any linux games. Ken ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: NVidia driver stability?
> I don't know if this is relevant, but the NVidia drivers won't work with > libkse or libthr, because it messes with the %gs segment register, which > both threading libraries use. The only threading library it currently > works with is libc_r. Actually from what I hear that's not accurate. It only works with the linuxthreads port. Ken ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: wierd dsl performance with -CURRENT
> You should visit the FreeBSD -performance list archives for a > (fairly) recent discussion on network performance (I believe > between a couple of us, we were able to come up with tuning > parameters that improved someone's file transfer performance by > about a factor of 10 for some tests). Remember the name of the thread? Ken ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: wierd dsl performance with -CURRENT
> This is the data transfer, so the d2c_* plots are the interesting ones > (they graph the traffic from ftp2 to you). If you load up d2c_tput.xpl, > you can see that your throughput averaged ~164K/s for almost the entire > time. The red line is the short-term average, and you can see there > were four dips, corresponding to packet loss. Flip over to the > d2c_tsg.xpl plot, which graphs the sent packets, ACKs, and the receive > window. At 21:52:32.8, it looks like four consecutive packets were > dropped. Luckily, the packets were resent quickly, and transmission > resumed at full speed. Dips 3 and 4 look the same. Dip 2 has an extra > .2 second delay for some reason. It looks like fast restransmit kicked > in on all three dips, but for some reason it didn't recover fast enough > on #2. A TCP guru will have to tell you what to do next... Well, the actual transfer occured around 145 - 150KB/sec according to the ftp program, normally that is 160KB/sec, and the average is around 10-15KB/sec higher after you factor out at least ftp, tcp, IP, and ethernet header. My bandwidth monitor dockapp shows around 176-164 when it's working right, but now it starts really slow and eventually gets to around the average you saw in the graphs. Ken ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: wierd dsl performance with -CURRENT
> In the last episode (Jul 09), Kenneth Culver said: > > > look of any large values in the timestamps and see if there is > > > anything before that indicates a lost packet or a re-ordered one or > > > something (or a retransmitted ack) > > > > > > The key is to find the gap in the arriving packets and figure out > > > what caused it.. > > > > > Alright, I'll have to do this later this evening, don't have time > > right now. Thanks for the help though. > > Tcptrace is great for this; the tsg output graph will mark out-of-order > packets and duplicate acks for you. > Alright, I used this and got a bunch of xpl graphs, but I'm not really sure what I'm looking at or for. The only graph I really understand is the d2c_tput.xpl, which is the thruput of the ftp data connection from ftp2.freebsd.org to my machine. I have posted the xpl's, along with the binary tcpdump output used to create the graphs. I've also posted the ascii output of the same download. All of these are posted at http://www.glue.umd.edu/~culverk/ the graphs are *.xpl, the binary output is tcpdump.out, and the ascii is tcpdump.ascii. Thanks. Ken PS Commands used: for tcpdump: binary tcpdump -ttt -w tcpdump.out host kenshin ascii tcpdump -ttt host kenshin | & tee tcpdump.ascii and to create graphs: tcptrace -GC tcpdump.out And the output of tcptrace: 1 arg remaining, starting with 'tcpdump.out' Ostermann's tcptrace -- version 6.3.2 -- Mon Oct 14, 2002 1756 packets seen, 1756 TCP packets traced elapsed wallclock time: 0:00:00.203206, 8641 pkts/sec analyzed trace file elapsed time: 0:00:09.670714 TCP connection info: 1: kenshin:49178 - ftp2.freebsd.org:21 (a2b) 9>8< 2: kenshin:49179 - ftp2.freebsd.org:58751 (c2d) 717> 1022< (complete) All the xpl and output files are at the site listed above. Thanks again ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: wierd dsl performance with -CURRENT
> > > Can you do a > > > 'netstat -s -p tcp >> tcpstats' before and after the transfer? > > > > > > This should tell us if there were retransmits etc. It could be a > > > difference in minimum rtt values or a congestion issue that results in > > > timeout for our stack but some other recovery mechanism with other stacks. > > > > > > > Here is the output of the netstat before and after transferring "kern.flp" > > for FreeBSD 5.1: > > > > tcp: > [...] > > 35600 packets received > > [...] > > 1220 out-of-order packets (1657153 bytes) > > > > This is after: > > > > tcp: > [...] > > 36688 packets received > > 1298 out-of-order packets (1770089 bytes) > > This is the only thing that is of any interest.. > and it could only really be if the etherent driver was re-ordering > them.. > > possibly FreeBSD 5 might react more to out-of-order packets.. > > capture a download with tcpdump > and save it (ascii version) to a file using the -ttt option to get > relative timestamps.. > > look of any large values in the timestamps and see if there is anything > before that indicates a lost packet or a re-ordered one or something > (or a retransmitted ack) > > The key is to find the gap in the arriving packets and figure out > what caused it.. > Alright, I'll have to do this later this evening, don't have time right now. Thanks for the help though. Ken ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: wierd dsl performance with -CURRENT
> > Transferring anything through the BSD NAT box shows the same performance > > issues, as well as transferring directly from BSD to the DSL modem on both > > of my BSD machines. Using windows or the mac directly connected to the DSL > > modem shows the normal bandwidth capability. I know the hardware isn't the > > problem, both of the BSD boxes are totally different. If you think it > > matters I can send the specs too. > > > > > > Ken > > Can you do a > 'netstat -s -p tcp >> tcpstats' before and after the transfer? > > This should tell us if there were retransmits etc. It could be a > difference in minimum rtt values or a congestion issue that results in > timeout for our stack but some other recovery mechanism with other stacks. > Here is the output of the netstat before and after transferring "kern.flp" for FreeBSD 5.1: tcp: 28727 packets sent 13954 data packets (3760142 bytes) 363 data packets (19245 bytes) retransmitted 8 data packets unnecessarily retransmitted 0 resends initiated by MTU discovery 9842 ack-only packets (1036 delayed) 0 URG only packets 0 window probe packets 2703 window update packets 1892 control packets 35600 packets received 14218 acks (for 3760605 bytes) 761 duplicate acks 0 acks for unsent data 23779 packets (18905861 bytes) received in-sequence 41 completely duplicate packets (9457 bytes) 0 old duplicate packets 0 packets with some dup. data (0 bytes duped) 1220 out-of-order packets (1657153 bytes) 0 packets (0 bytes) of data after window 0 window probes 3 window update packets 7 packets received after close 1 discarded for bad checksum 0 discarded for bad header offset fields 0 discarded because packet too short 789 connection requests 679 connection accepts 0 bad connection attempts 0 listen queue overflows 1427 connections established (including accepts) 1466 connections closed (including 335 drops) 17 connections updated cached RTT on close 17 connections updated cached RTT variance on close 1 connection updated cached ssthresh on close 7 embryonic connections dropped 13345 segments updated rtt (of 13120 attempts) 565 retransmit timeouts 4 connections dropped by rexmit timeout 0 persist timeouts 0 connections dropped by persist timeout 0 keepalive timeouts 0 keepalive probes sent 0 connections dropped by keepalive 1216 correct ACK header predictions 15958 correct data packet header predictions 691 syncache entries added 34 retransmitted 28 dupsyn 1 dropped 679 completed 0 bucket overflow 0 cache overflow 8 reset 4 stale 0 aborted 0 badack 0 unreach 0 zone failures 0 cookies sent 0 cookies received This is after: tcp: 29493 packets sent 14005 data packets (3761865 bytes) 363 data packets (19245 bytes) retransmitted 8 data packets unnecessarily retransmitted 0 resends initiated by MTU discovery 10238 ack-only packets (1040 delayed) 0 URG only packets 0 window probe packets 3020 window update packets 1894 control packets 36688 packets received 14269 acks (for 3762329 bytes) 761 duplicate acks 0 acks for unsent data 24759 packets (20268809 bytes) received in-sequence 41 completely duplicate packets (9457 bytes) 0 old duplicate packets 0 packets with some dup. data (0 bytes duped) 1298 out-of-order packets (1770089 bytes) 0 packets (0 bytes) of data after window 0 window probes 3 window update packets 7 packets received after close 1 discarded for bad checksum 0 discarded for bad header offset fields 0 discarded because packet too short 790 connection requests 679 connection accepts 0 bad connection attempts 0 listen queue overflows 1428 connections established (including accepts) 1467 connections closed (including 335 drops) 17 connections updated cached RTT on close 17 connections up
Re: wierd dsl performance with -CURRENT
> AH so it's direct DSL with either a fixed IP or DHCP or similar? Yep, basically I don't have a DSL modem, I have an Ethernet to ATM bridge (using AAL5 encapsulation I believe) running over the DSL. I have 2 fixed IP's, and in my normal configuration, my two BSD boxes are hooked up to a switch that also hooks to the DSL modem. One of my BSD boxes also runs ipfilter/ipnat/dnscache/dhcpd/postfix for my local mail and to allow the other 4 people living in the house, as well as my mac (macos X 10.2.6), my pc laptop, and my dreamcast to access the internet. That should be enough info :-) > in that case, then what does it look like speed-wise if you transfer > from the internet to the MAC using the BSD machine as a router? > Transferring anything through the BSD NAT box shows the same performance issues, as well as transferring directly from BSD to the DSL modem on both of my BSD machines. Using windows or the mac directly connected to the DSL modem shows the normal bandwidth capability. I know the hardware isn't the problem, both of the BSD boxes are totally different. If you think it matters I can send the specs too. Ken ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: wierd dsl performance with -CURRENT
> Just as an experiment, try setting "net.inet.tcp.newreno" to 0 using > sysctl(8). It might help; it might not. Please let us know. It didn't help. I also tried setting several other sysctl OID's in net.inet.tcp, but nothing helped. I'm totally out of ideas for why this could be happening. I mean it IS only 16KB/sec, but it seems wierd that only FreeBSD is having problems out of all the OS's I use at home. Ken ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: wierd dsl performance with -CURRENT
> I think he is timing transfers from a Mac THROUGH the BSD box.. > If so then a change in throughput would be due to a change in ppp > behaviour.. No, I hooked the mac straight to the DSL modem, and also did the same with the windows box. > > It would be interesting to see if it changed with > 1/ using mpd as the ppp client (as it uses an in-kernel pp node) > 2/ ULE changes anything (as it may be that it's a scheduler thing > with ppp being a user program). > I'm not using ppp, I use speakeasy and they don't use PPPoE. Ken ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
wierd dsl performance with -CURRENT
Hi, Recently, for some wierd reason, with FreeBSD-CURRENT my DSL downloads have gotten about 10-15 KB/sec slower than they used to be.. I used to get 160KB/sec downloads, and now can only manage about 145. I was wondering if there are any ideas what is causing this. I'm sure it's a FreeBSD problem because when I boot up windows or hook my mac straight to the dsl modem, each of those gets the full 160KB/sec download (from the same site, ftp2.freebsd.org) but when I download from FreeBSD, the speed drops. I'm not sure if this happens in -STABLE, but it started happening sometime within the last month or 1.5 months. I tried checking out a cvs repository, then checking out FreeBSD-CURRENT from as early as 5/28/03 (uname -a shows 5.1-BETA), and I still see the problem. I'm going to try checking out one from mid-May and see if the problem still exists, but I was wondering if there is some kernel option or something similar that could be causing my problem. Thanks. Ken ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: NVidia kernel driver support for FreeBSD-5.1
> On Wednesday 18 June 2003 16:05, Kenneth Culver wrote: > > > #pciconf -l -v > > > > > > [EMAIL PROTECTED]:12:0:class=0x03 card=0x chip=0x002d10de > > > rev=0x15 hdr=0x00 vendor = 'NVIDIA Corporation' > > > device = 'NV5 TNT2 Model 64 / TNT2 Model 64 Pro' > > > > > > This is my video card, which sounds just like yours. I have it working > > > fine with the native XFree 'nv' module, but two caveats: > > > > The nv module won't support 3d acceleration. IF you want 3d accel, you > > have to use nvidia's binary driver. > > Hello! > > I've got exactly that video card :) > > So...the best way is using the ports collection, > do I still have to delete "options INVARIANT" and recompile > the kernel ? It's very painful for me to compile things because > I've got an old computer (Pentium MMX 200Mhz) and it takes > long time to compile the kernel, so if I can still use both the kernel > with INVARIANTS and install the nvidia-port, I'd be delighted. > > I'm not at home yet :( > > Thanks! You will most likely have to remove INVARIANT as well if you are running the GENERIC kernel. If you've never recompiled your kernel, then most likely you are running the GENERIC kernel. If you have recompiled your kernel, just make sure you've taken that option out. Ken ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: NVidia kernel driver support for FreeBSD-5.1
> #pciconf -l -v > > [EMAIL PROTECTED]:12:0:class=0x03 card=0x chip=0x002d10de > rev=0x15 hdr=0x00 > vendor = 'NVIDIA Corporation' > device = 'NV5 TNT2 Model 64 / TNT2 Model 64 Pro' > > This is my video card, which sounds just like yours. I have it working > fine with the native XFree 'nv' module, but two caveats: The nv module won't support 3d acceleration. IF you want 3d accel, you have to use nvidia's binary driver. > > First, once you have installed the driver from NVidia, your /usr/X11 > tree will contain files that prevent the native 'nv' module from working. > I was never able to figure out which files were responsible so I finally > deleted the entire /usr/X11 tree and reinstalled everything from scratch. > > Second, you must be very careful which modules you load in your XF86Config. > There is at least one module which will prevent everything from working-- > unfortuneately I can't remember which one :0( > > Section "Module" > Load "extmod" > Load "xie" > Load "pex5" > Load "dbe" > Load "record" > Load "xtrap" > Load "speedo" > # Load "glx" > Load "type1" > Load "freetype" > EndSection > > Notice that I have 'glx' commented out -- I think that's the reason I > did that, but it was a long time ago. You did it because the nvidia binary drivers require you to. Ken ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: NVidia kernel driver support for FreeBSD-5.1
> I've got a PCI-NVidia Riva TNT 64 video card at home, > and I've tried to compile the drivers but it doesn't work, > and after changing the source to let the compilation progress, > when the module is loaded I've received a "kernel panic". > > Im using FreeBSD-5.1 with XFree86-4.3, what can I do > to solve this issue ? I can not run the X system using > the "nv" driver, my computer hangs up. > Try using the port of the driver instead of doing things manually: cd /usr/ports/x11/nvidia-driver make make install That should apply the proper patches to the kernel part of the driver. If it doesn't, it's possible your ports tree is out of date. Ken ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: New Kernel Breaks IPFW
Try rebuilding ipfw. Ken On Mon, 9 Jun 2003, John Stockdale wrote: > Hey everyone, > > I just cvsup'd my src today and was going to buildworld later tonight > but when I installed the newly built kernel with IPFIREWALL etc. and > rebooted, ipfw fell over, specifically, even after ipfw firewall enable, > an ipfw show resulted in a core dump. If its useful, I can post the ipfw > core dump. > > Any ideas why this is? > > Thanks > > -John > > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP! Major commits in the tree coming soon
> The HEAD code freeze was extended by three days to > allow for some final pending work to be committed and > prepare 5.1 to be a good release. The code freeze will > > likely end sometime tomorrow, May 30. > > We ask that large scale changes still be deferred > until after 5.1 is actually released so that any > problems can be dealt with. The release > engineering team will send out emails explicitely > stating when HEAD has thawed and when large changes > like new compilers and dynamic-linked worlds can go > it. > > The most important changes I'm going to commit today: > > - Remove gcc and replace it with a new TenDRA > snapshot. I'm just wondering... but is there a reason why gcc is being replaced? Is there a page or a previous list mail that explains the reasons? URL? Thanks. > - Remove GNU tar. > - Fix httpd.ko to make it work on buggy AMD > processors. > - Drop support for 386 and 486 cpus. > - Remove ext2 support (GPL encumbered). > - Add perl 5.8 *and* python 2.2 to base. > - Remove Sendmail and replace it with Postfix. > > If anyone has any reason why these should not be > committed, I'll give a 5 hours grace time. Send > replies > to the list. > > Thank you. > > Thorsten and the rest or the release engineering team. > Thanks Ken ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: linux-emu ioctl not implemented w/ quake3
I'd say this is a video card driver issue, because with my geforce3 and
the nvidia drivers I could run q3 for as long as I wanted without any
issues.
Ken
On Thu, 3 Apr 2003, Matthias Buelow wrote:
> Hi folks,
>
> I'm running 5.0-RELEASE-p7 on i386 and investigated how quake3 (linux)
> would be doing at the moment. I had some relative success on 4.7
> (quake3 ran ok, in 3d acceleration, but only for about 30 seconds, at
> which point the whole machine froze solid) so I hoped it might just
> work out. This time at least it didn't freeze but I don't even get so
> far. When I run quake3.x86, I get the following:
>
> quake3 spits:
>
> Using XFree86-VidModeExtension Version 2.2
> XFree86-VidModeExtension Activated at 640x480
> libGL error: failed to open DRM: Operation not permitted
> ...
> (at which point it offers me to use Mesa software rendering
> as a fallback which, of course, works...)
>
> and the kernel says:
>
> Apr 3 04:59:23 reiher kernel: linux: 'ioctl' fd=13, cmd=0x6401 ('d',1) not
> implemented
>
> Does anybody know what ioctl that would be? I didn't get that on 4.7,
> is linux-emu divergent between -stable and -current?
>
> The relevant ktrace excerpt follows:
>
> ...
> 1713 quake3.x86 RET old.setrlimit 12/0xc
> 1713 quake3.x86 CALL ftruncate
> 1713 quake3.x86 RET ftruncate 1000/0x3e8
> 1713 quake3.x86 CALL setrlimit(0x2cea6c30,0xbfbfea00,0)
> 1713 quake3.x86 NAMI "/compat/linux/dev/dri"
> 1713 quake3.x86 NAMI "/dev/dri"
> 1713 quake3.x86 RET setrlimit 0
> 1713 quake3.x86 CALL setrlimit(0xbfbfeb00,0xbfbfea00,0)
> 1713 quake3.x86 NAMI "/compat/linux/dev/dri/card0"
> 1713 quake3.x86 NAMI "/dev/dri/card0"
> 1713 quake3.x86 RET setrlimit 0
> 1713 quake3.x86 CALL open(0xbfbfeb00,0x2,0)
> 1713 quake3.x86 NAMI "/compat/linux/dev/dri/card0"
> 1713 quake3.x86 NAMI "/dev/dri/card0"
> 1713 quake3.x86 RET open 13/0xd
> 1713 quake3.x86 CALL ioctl(0xd,0xc0086401 ,0xbfbfec00)
> 1713 quake3.x86 RET ioctl -1 errno -22 Unknown error: -22
> 1713 quake3.x86 CALL close(0xd)
> 1713 quake3.x86 RET close 0
> 1713 quake3.x86 CALL ftruncate
> 1713 quake3.x86 RET ftruncate 1000/0x3e8
> 1713 quake3.x86 CALL setrlimit(0x2cea6c30,0xbfbfea00,0)
> 1713 quake3.x86 NAMI "/compat/linux/dev/dri"
> 1713 quake3.x86 NAMI "/dev/dri"
> 1713 quake3.x86 RET setrlimit 0
> 1713 quake3.x86 CALL setrlimit(0xbfbfeb00,0xbfbfea00,0)
> 1713 quake3.x86 NAMI "/compat/linux/dev/dri/card1"
> 1713 quake3.x86 NAMI "/dev/dri/card1"
> 1713 quake3.x86 RET setrlimit JUSTRETURN
> 1713 quake3.x86 CALL ftruncate
> 1713 quake3.x86 RET ftruncate 1000/0x3e8
> 1713 quake3.x86 CALL setrlimit(0x2cea6c30,0xbfbfea00,0)
> 1713 quake3.x86 NAMI "/compat/linux/dev/dri"
> 1713 quake3.x86 NAMI "/dev/dri"
> 1713 quake3.x86 RET setrlimit 0
> 1713 quake3.x86 CALL setrlimit(0xbfbfeb00,0xbfbfea00,0)
> 1713 quake3.x86 NAMI "/compat/linux/dev/dri/card2"
> 1713 quake3.x86 NAMI "/dev/dri/card2"
> 1713 quake3.x86 RET setrlimit JUSTRETURN
> 1713 quake3.x86 CALL ftruncate
> 1713 quake3.x86 RET ftruncate 1000/0x3e8
> 1713 quake3.x86 CALL setrlimit(0x2cea6c30,0xbfbfea00,0)
> 1713 quake3.x86 NAMI "/compat/linux/dev/dri"
> 1713 quake3.x86 NAMI "/dev/dri"
> 1713 quake3.x86 RET setrlimit 0
> 1713 quake3.x86 CALL setrlimit(0xbfbfeb00,0xbfbfea00,0)
> 1713 quake3.x86 NAMI "/compat/linux/dev/dri/card3"
> 1713 quake3.x86 NAMI "/dev/dri/card3"
> 1713 quake3.x86 RET setrlimit JUSTRETURN
> 1713 quake3.x86 CALL ftruncate
> 1713 quake3.x86 RET ftruncate 1000/0x3e8
> 1713 quake3.x86 CALL setrlimit(0x2cea6c30,0xbfbfea00,0)
> 1713 quake3.x86 NAMI "/compat/linux/dev/dri"
> 1713 quake3.x86 NAMI "/dev/dri"
> 1713 quake3.x86 RET setrlimit 0
> 1713 quake3.x86 CALL setrlimit(0xbfbfeb00,0xbfbfea00,0)
> 1713 quake3.x86 NAMI "/compat/linux/dev/dri/card4"
> 1713 quake3.x86 NAMI "/dev/dri/card4"
> 1713 quake3.x86 RET setrlimit JUSTRETURN
> 1713 quake3.x86 CALL ftruncate
> 1713 quake3.x86 RET ftruncate 1000/0x3e8
> 1713 quake3.x86 CALL setrlimit(0x2cea6c30,0xbfbfea00,0)
> 1713 quake3.x86 NAMI "/compat/linux/dev/dri"
> 1713 quake3.x86 NAMI "/dev/dri"
> 1713 quake3.x86 RET setrlimit 0
> 1713 quake3.x86 CALL setrlimit(0xbfbfeb00,0xbfbfea00,0)
> 1713 quake3.x86 NAMI "/compat/linux/dev/dri/card5"
> 1713 quake3.x86 NAMI "/dev/dri/card5"
> 1713 quake3.x86 RET setrlimit JUSTRETURN
> 1713 quake3.x86 CALL ftruncate
> 1713 quake3.x86 RET ftruncate 1000/0x3e8
> 1713 quake3.x86 CALL setrlimit(0x2cea6c30,0xbfbfea00,0)
> 1713 quake3.x86 NAMI "/compat/linux/dev/dri"
> 1713 quake3.x86 NAMI "/dev/dri"
> 1713 quake3.x86 RET setrlimit 0
> 1713 quake3.x86 CALL setrlimit(0xbfbfeb00,0xbfbfea00,0)
> 1713 quake3.x86 NAMI "/compat/linux/dev/dri/card6"
> 1713 quake3.x86 NAMI "/dev/dri/card6"
> 1713 quake3.x86 RET setrlimit JUSTRETURN
> 1713 quake3.x86 CALL ftruncate
> 171
Re: Hyperthreading and machdep.cpu_idle_hlt
> I have HTT for my CPU, is there any "hack" to the BIOS to enable > HyperThreading? > You might try updating your BIOS. Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD panic with umass
I've only had time to do minimal testing, but no panics anymore with this patch. Ken On Mon, 27 Jan 2003, MIHIRA Sanpei Yoshiro wrote: > I forgot to add below changes. > > Please apply this patch and > # make -f Makefile.usbdevs > > Cheers > > - sanpei > > > Index: sys/dev/usb/usbdevs > === > RCS file: /home/ncvs/src/sys/dev/usb/usbdevs,v > retrieving revision 1.106 > diff -u -r1.106 usbdevs > --- sys/dev/usb/usbdevs 21 Jan 2003 11:37:54 - 1.106 > +++ sys/dev/usb/usbdevs 26 Jan 2003 21:48:19 - > @@ -626,6 +626,11 @@ > /* Fuji photo products */ > product FUJIPHOTO MASS0100 0x0100 Mass Storage > > +/* Genesys Logic products */ > +product GENESYS GL650 0x0604 GL650 Hub > +product GENESYS GL641USB0x0700 GL641USB CompactFlash Card Reader > +product GENESYS GL641USB2IDE0x0702 GL641USB USB-IDE Bridge > + > /* Hagiwara products */ > product HAGIWARA FGSM0x0002 FlashGate SmartMedia Card Reader > product HAGIWARA FGCF0x0003 FlashGate CompactFlash Card Reader > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: VMWare 3.2 on FreeBSD
No. On Sun, 26 Jan 2003, Theodoor van der Kooij wrote: > Hi all, > > is there a way to run VMWare 3.2 on FreeBSD 5.0? > > regards, > > Theodoor van der Kooij. > -- > Windows: "Where do you want to go today?" > Linux: "Where do you want to go tomorrow?" > FreeBSD: "Are you guys coming, or what?" > > > 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: FreeBSD panic with umass
I actually just went and got a sandisk card reader instead but I'll test
your changes anyway, since I still have the genesys one.
Ken
On Mon, 27 Jan 2003, MIHIRA Sanpei Yoshiro wrote:
> I have GENESYS USB2IDE Interface Card(GL641). And I also have
> same problem(umass0: BBB bulk-in clear stall failed, IOERROR)
>
> NetBSD was aleady fixed
> http://www.netbsd.org/cgi-bin/query-pr-single.pl?number=19971
> http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/usb/umass_scsipi.c
>
> I created patch for FreeBSD-current. Try this one.
>
> May I commit this changes?
>
> ---
> MIHIRA, Sanpei Yoshiro
> Tokyo, Japan.
>
> Index: sys/dev/usb/umass.c
> ===
> RCS file: /home/ncvs/src/sys/dev/usb/umass.c,v
> retrieving revision 1.71
> diff -u -r1.71 umass.c
> --- sys/dev/usb/umass.c 21 Jan 2003 08:55:44 - 1.71
> +++ sys/dev/usb/umass.c 26 Jan 2003 17:54:45 -
> @@ -373,6 +373,16 @@
> UMASS_PROTO_ATAPI | UMASS_PROTO_CBI_I,
> FORCE_SHORT_INQUIRY
> },
> + /* sanpei */
> + { USB_VENDOR_GENESYS, 0x0702 /* GENESYS_GL641USB2 */, RID_WILDCARD,
> + UMASS_PROTO_SCSI | UMASS_PROTO_BBB,
> + FORCE_SHORT_INQUIRY | NO_START_STOP | IGNORE_RESIDUE
> + },
> + /* sanpei */
> + { USB_VENDOR_GENESYS, GL641USB, RID_WILDCARD,
> + UMASS_PROTO_SCSI | UMASS_PROTO_BBB,
> + FORCE_SHORT_INQUIRY | NO_START_STOP | IGNORE_RESIDUE
> + },
>
> { VID_EOT, PID_EOT, RID_EOT, 0, 0 }
> };
> @@ -2367,6 +2377,11 @@
>*/
>
> if (sc->transform(sc, cmd, cmdlen, &rcmd, &rcmdlen)) {
> +#if 1 /* XXX sanpei */
> + if ((sc->quirks & FORCE_SHORT_INQUIRY) && (rcmd[0] ==
>INQUIRY)) {
> + csio->dxfer_len = SHORT_INQUIRY_LENGTH;
> + }
> +#endif
> sc->transfer(sc, ccb->ccb_h.target_lun, rcmd, rcmdlen,
>csio->data_ptr,
>csio->dxfer_len, dir,
> @@ -2559,6 +2574,11 @@
> (unsigned char *) &sc->cam_scsi_sense,
> sizeof(sc->cam_scsi_sense),
> &rcmd, &rcmdlen)) {
> +#if 1 /* XXX sanpei */
> + if ((sc->quirks & FORCE_SHORT_INQUIRY) && (rcmd[0] ==
>INQUIRY)) {
> + csio->sense_len = SHORT_INQUIRY_LENGTH;
> + }
> +#endif
> sc->transfer(sc, ccb->ccb_h.target_lun,
>rcmd, rcmdlen,
>&csio->sense_data,
> @@ -2750,6 +2770,18 @@
> return 1;
> }
> /* fallthrough */
> +#if 1 /* XXX sanpei */
> + case INQUIRY:
> + /* some drives wedge when asked for full inquiry information. */
> + if (sc->quirks & FORCE_SHORT_INQUIRY) {
> + memset(*rcmd, 0, cmdlen);
> + memcpy(*rcmd, cmd, cmdlen);
> + *rcmdlen = cmdlen;
> + (*rcmd)[4] = SHORT_INQUIRY_LENGTH;
> + return 1;
> + }
> + /* fallthrough */
> +#endif
> default:
> *rcmd = cmd;/* We don't need to copy it */
> *rcmdlen = cmdlen;
>
> 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: /dev/dsp disappears while being used
This may be related to the vchans stuff in in the pcm driver. Ken On Thu, 23 Jan 2003, Juli Mallett wrote: > * De: Alexander Langer <[EMAIL PROTECTED]> [ Data: 2003-01-23 ] > [ Subjecte: /dev/dsp disappears while being used ] > > When I then symbolically link /dev/dsp to one of the dspX.X devices, > > XMMS can play sound for some more time, but then these are disappearing > > as well. > > > > Is this a devfs bug? I almost think so, but I'm not sure. > > Not sure. I always just get dsp to "re-appear" (I think it gets re- > cloned) by doing "cat /dev/dsp0.0" for a second. > -- > 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. > > 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: 5.0-RELEASE & VMWare 3.2
the vmware people don't list 5.0 as a supported os... theres probably a reason for this. Ken On Thu, 23 Jan 2003, Lev Serebryakov wrote: > Hello, current! How are you? > > When I needed to experiment with 4.6-RELEASE and I didn't have > ``free'' computer, I installed 4.6-RELEASE on VMWare. It works > pretty well and I was totally satisfied. > > My host is: 2xP!!!-770Mhz, 512Mb of memory, Hardware RAID with > 2x40Gb IBM IDE HDDs (and one simple system disk). Host OS is W'2000 WS. > > Now I'm trying to look at 5.0-RELEASE (I've downloaded ISO of first > i386 CD). > > It doesn't work under VMWare 3.2! Ok, it works, really. But speed is > VERY low. I even could not do installation! Unpacking of > distributive have been started at normal speed, but after 2 or 3 > minutes speed decreased to 6Kb/s and after that to 1Kb/s! `top' on > emergency console shows, that cpio+gunzip take only 5% of CPU, > system takes 25% of CPU and interrupts takes 70% of CPU! > > 4.6-RELEASE installs on same VMWare virtual computer without any > problems and works very fast! > > Is it problem of VMWare or 5.0-RELEASE? Is it known problem? I could > provide any additional information, if needed. > >Lev Serebryakov > /---\ > | FIDONet: 2:5030/661.0 | > | E-Mail: [EMAIL PROTECTED] | > | Page:http://lev.serebryakov.spb.ru/ | > | ICQ UIN: 3670018 | > | Phone: You know, if you have world nodelist | > \===/ > > > 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: Performance problems with 5.0-RELEASE
> I hope someone could bring light to what's going on. Alltho I'm not > whining, I knew what I was getting myself into when I installed 5.0, it > would be nice get things solved, for FreeBSD's sake already. Did you by any chance build your own kernel? If so did you leave things like this in: options INVARIANTS #Enable calls of extra sanity options INVARIANT_SUPPORT #Extra sanity checks of internal options WITNESS #Enable checks to detect deadlocks options WITNESS_SKIPSPIN#Don't run witness on spinlocks These will significantly slow down a FreeBSD machine. They're there mainly for debugging purposes, but if you want speed you should take them out. Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD panic with umass
here are a few pointers when you look at the linux driver:
several devices in linux/drivers/usb/storage/unusual_devs.h have the quirk
flag: US_FL_FIX_INQUIRY. in the same directory, searching for
USB_FL_FIX_INQUIRY yields the following in usb.c:
/* Handle those devices which need us to fake
* their inquiry data */
if ((us->srb->cmnd[0] == INQUIRY) &&
(us->flags & US_FL_FIX_INQUIRY)) {
unsigned char data_ptr[36] = {
0x00, 0x80, 0x02, 0x02,
0x1F, 0x00, 0x00, 0x00};
US_DEBUGP("Faking INQUIRY command\n");
fill_inquiry_response(us, data_ptr, 36);
us->srb->result = GOOD << 1;
So unless I'm reading it wrong, this device can't respond to a basic
inquiry :-P
Ken
> I'll take a look at the Linux driver but I'd be very surprised if the
> device can't even respond to a basic inquiry (extended inquiry could
> cause problems).
>
> -Nate
>
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD panic with umass
I figured out something new on this device: Basically in linux, in order for this device to work, the INQUIRY data has to be faked. Just in case you forgot, this is the Genesys Logic Compact Flash reader/writer. There is some whole big set of crap the driver goes through in linux just to fake the data and send it up to the scsi layer. So no matter what, any quirks I put in the scsi layer won't even be found because FreeBSD can't even do an Inquiry on the device. Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD panic with umass
On Mon, 20 Jan 2003, Matthew Dillon wrote: > :Hmm, good stuff, but shouldn't something be committed anyway? I mean if it > :causes a panic just by plugging in the device that's totally unacceptable. > :I'll provide a backtrace of the crash on my computer tomorrow I suppose (I > :won't be home until then) and let people know if that's what's causing my > :crash. > : > :Ken > > Yes, but it isn't quite that easy. I did fix the incorrect sense > code issue with UMASS, but that's only one of the potentially many > problems that could occur. It would probably also help (give us more > deterministic panics / errors) if the read_capacity structure were > at least bzero'd by CAM/SCSI. > > But half the problem is with the USB devices themselves. The device > firmware for many of these devices, especially the Sony, was written > by idiots. The entire USB specification was written by idiots IMHO. > For example, the Sony will respond with garbage, and no error whatsoever, > to just about any page inquiry command you send it. The Sony doesn't > even return reasonable data for the code pages that the USB spec requires! > > Ultimately this means that the best we can do is to try to ensure that > garbage data doesn't result in a system panic. That's a fairly tall > order for such a low level subsystem. > Yeah, I suppose I understand your point. I could probably at least take a look at doing some modifications here and there to avoid crashes at least. Even with everything you said, it's still the case that we shouldn't allow just plugging in a device to cause a panic. Maybe we should just not try to attach a device we don't know about? Meaning no wildcard matches in the USB code for the probe/attach. That would solve the problem since we wouldn't be attaching anything we don't know about. Then people could submit pr's or whatever with the device ID's for their devices, and the quirks that device needs in order to work. Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD panic with umass
> :Backtrace would be useful since you shouldn't be getting a panic. At the
> :worst, your usb reader just wouldn't work.
> :
> :-Nate
>
> At worse the system will crash. The problem is that USB devices
> sometimes return total garbage for the READ CAPACITY command. This
> isn't CAM's fault, it is a major issue with the way the USB code works
> as well as a major issue with the way certain USB devices respond
> to commands (or request lengths) that they do not understand. Sometimes
> the USB layer does not get an error or returns the wrong sense code.
> The USB code can also somtimes get out of sync with the device between
> commands, causing all sorts of havoc.
>
> When I was tracking down the Sony DiskKey problem I hit this problem.
> The Sony often returned complete garbage for READ CAPACITY until I put
> the proper quirk entries in. Since the CAM/SCSI layer does not bzero()
> the scsi_read_capacity_data structure, the result was random capacities
> and system crashes (e.g. when a certain value would wind up 0 the CAM
> layer would crash with a divide by 0).
>
> I added some debugging to try to catch the problem and it still happens
> to be in my tree so I can give you guys the diff. This is *NOT* for
> commit. It's just junk debugging code. Note that I added the M_ZERO
> option to the malloc.
>
> -Matt
Hmm, good stuff, but shouldn't something be committed anyway? I mean if it
causes a panic just by plugging in the device that's totally unacceptable.
I'll provide a backtrace of the crash on my computer tomorrow I suppose (I
won't be home until then) and let people know if that's what's causing my
crash.
Ken
>
> Index: scsi_da.c
> ===
> RCS file: /home/ncvs/src/sys/cam/scsi/scsi_da.c,v
> retrieving revision 1.42.2.30
> diff -u -r1.42.2.30 scsi_da.c
> --- scsi_da.c 20 Dec 2002 15:20:25 - 1.42.2.30
> +++ scsi_da.c 30 Dec 2002 23:22:22 -
> @@ -546,8 +556,10 @@
>
> rcap = (struct scsi_read_capacity_data *)malloc(sizeof(*rcap),
> M_TEMP,
> - M_WAITOK);
> -
> + M_WAITOK|M_ZERO);
> + scsi_ulto4b(313, (void *)&rcap->length);
> + scsi_ulto4b(512, (void *)&rcap->addr);
> +
> ccb = cam_periph_getccb(periph, /*priority*/1);
> scsi_read_capacity(&ccb->csio,
> /*retries*/1,
> @@ -1187,6 +1199,7 @@
> softc->minimum_cmd_size = 10;
> else
> softc->minimum_cmd_size = 6;
> + printf("QUIRKS %04x MCS %d MATCH %p\n", softc->quirks,
>softc->minimum_cmd_size, match);
>
> /*
>* Block our timeout handler while we
> @@ -1748,6 +1761,8 @@
> dp = &softc->params;
> dp->secsize = scsi_4btoul(rdcap->length);
> dp->sectors = scsi_4btoul(rdcap->addr) + 1;
> + printf("RDCAP SECSIZE %d\n", (int)dp->secsize);
> + printf("RDCAP SECTORS %d\n", (int)dp->sectors);
> /*
>* Have the controller provide us with a geometry
>* for this disk. The only time the geometry
> @@ -1767,6 +1782,7 @@
> dp->heads = ccg.heads;
> dp->secs_per_track = ccg.secs_per_track;
> dp->cylinders = ccg.cylinders;
> + printf("RDCAP HEADS %d SPT %d CYL %d\n", (int)ccg.heads,
>(int)ccg.secs_per_track, (int)ccg.cylinders);
> }
>
> static void
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD panic with umass
> To start, copy a quirk entry and wildcard a lot: > "Genesys*", "*", "*" > > Then do camcontrol inquiry daX and change the quirk to be more specific. > > Backtrace would be useful since you shouldn't be getting a panic. At the > worst, your usb reader just wouldn't work. > > -Nate > > That was what I was going to try the next time I'm on that computer. I'm not going to be home to try it for a couple of days though, but I'll let people know, and file a PR with the fix once I have it. Yeah, I'll have a backtrace soon too, I think it's related to GEOM though based on what I saw when I booted with boot -v. There is no da0 but GEOM seems to think there is. I don't know what's causing the STABLE panic, but I think that's what's causing the -CURRENT one. Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD panic with umass
> > Hi, > > I just tried to use a Genesys Logic USB Compact Flash card reader, > > and the following messages come up, followed by a panic: > > > > Jan 19 19:41:30 kenshin kernel: umass0: Genesys Logic USB Storage Device, > > rev 1. > > 10/1.13, addr 2 > > Jan 19 19:41:30 kenshin kernel: umass0: Get Max Lun not supported > > (STALLED) > > Jan 19 19:41:30 kenshin kernel: umass0: BBB reset failed, IOERROR > > Jan 19 19:41:30 kenshin kernel: umass0: BBB bulk-in clear stall failed, > > IOERROR > > Jan 19 19:41:30 kenshin kernel: umass0: BBB bulk-out clear stall failed, > > IOERROR > > > > After this, FreeBSD panics. I havn't had time to get a full backtrace, but > > I'll send that once I get it. In the mean-time, is there any fix for the > > error I'm getting? > > > > > > Ken > > > > > > I get this on both -current, and -stable :( > > in this case, I was using my digital camera as a umass device. > > -Trish > I think I know what the problem is. Basically a lot of devices have problems with I guess the 6 byte commands... if you look in scsi_da.c you can find several "quirks" entries. I'm working on figuring out what to put for my vendor and product id's in order to add the quirk for my device. Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
FreeBSD panic with umass
Hi, I just tried to use a Genesys Logic USB Compact Flash card reader, and the following messages come up, followed by a panic: Jan 19 19:41:30 kenshin kernel: umass0: Genesys Logic USB Storage Device, rev 1. 10/1.13, addr 2 Jan 19 19:41:30 kenshin kernel: umass0: Get Max Lun not supported (STALLED) Jan 19 19:41:30 kenshin kernel: umass0: BBB reset failed, IOERROR Jan 19 19:41:30 kenshin kernel: umass0: BBB bulk-in clear stall failed, IOERROR Jan 19 19:41:30 kenshin kernel: umass0: BBB bulk-out clear stall failed, IOERROR Jan 19 19:41:30 kenshin kernel: umass0: BBB reset failed, IOERROR Jan 19 19:41:30 kenshin kernel: umass0: BBB bulk-in clear stall failed, IOERROR Jan 19 19:41:30 kenshin kernel: umass0: BBB bulk-out clear stall failed, IOERROR Jan 19 19:41:30 kenshin kernel: umass0: BBB reset failed, IOERROR Jan 19 19:41:30 kenshin kernel: umass0: BBB bulk-in clear stall failed, IOERROR Jan 19 19:41:30 kenshin kernel: umass0: BBB bulk-out clear stall failed, IOERROR Jan 19 19:41:30 kenshin kernel: umass0: BBB reset failed, IOERROR Jan 19 19:41:30 kenshin kernel: umass0: BBB bulk-in clear stall failed, IOERROR Jan 19 19:41:30 kenshin kernel: umass0: BBB bulk-out clear stall failed, IOERROR Jan 19 19:41:30 kenshin kernel: umass0: BBB reset failed, IOERROR Jan 19 19:41:30 kenshin kernel: umass0: BBB bulk-in clear stall failed, IOERROR Jan 19 19:41:30 kenshin kernel: umass0: BBB bulk-out clear stall failed, IOERROR Jan 19 19:41:30 kenshin kernel: umass0: BBB reset failed, IOERROR Jan 19 19:41:30 kenshin kernel: umass0: BBB bulk-in clear stall failed, IOERROR Jan 19 19:41:31 kenshin kernel: umass0: BBB bulk-out clear stall failed, IOERROR Jan 19 19:41:31 kenshin kernel: umass0: BBB reset failed, IOERROR Jan 19 19:41:31 kenshin kernel: umass0: BBB bulk-in clear stall failed, IOERROR Jan 19 19:41:31 kenshin kernel: umass0: BBB bulk-out clear stall failed, IOERROR Jan 19 19:41:31 kenshin kernel: umass0: BBB reset failed, IOERROR Jan 19 19:41:31 kenshin kernel: umass0: BBB bulk-in clear stall failed, IOERROR Jan 19 19:41:31 kenshin kernel: umass0: BBB bulk-out clear stall failed, IOERROR Jan 19 19:41:31 kenshin kernel: umass0: BBB reset failed, IOERROR Jan 19 19:41:31 kenshin kernel: umass0: BBB bulk-in clear stall failed, IOERROR Jan 19 19:41:31 kenshin kernel: umass0: BBB bulk-out clear stall failed, IOERROR Jan 19 19:41:31 kenshin kernel: umass0: BBB reset failed, IOERROR Jan 19 19:41:31 kenshin kernel: umass0: BBB bulk-in clear stall failed, IOERROR Jan 19 19:41:31 kenshin kernel: umass0: BBB bulk-out clear stall failed, IOERROR Jan 19 19:41:31 kenshin kernel: umass0: BBB reset failed, IOERROR Jan 19 19:41:31 kenshin kernel: umass0: BBB bulk-in clear stall failed, IOERROR Jan 19 19:41:31 kenshin kernel: umass0: BBB bulk-out clear stall failed, IOERROR Jan 19 19:41:31 kenshin kernel: (da0:umass-sim0:0:0:0): got CAM status 0x4 Jan 19 19:41:31 kenshin kernel: (da0:umass-sim0:0:0:0): fatal error, failed to a ttach to device Jan 19 19:41:31 kenshin kernel: (da0:umass-sim0:0:0:0): lost device Jan 19 19:41:31 kenshin kernel: umass0: BBB reset failed, IOERROR Jan 19 19:41:31 kenshin kernel: umass0: BBB bulk-in clear stall failed, IOERROR Jan 19 19:41:31 kenshin kernel: umass0: BBB bulk-out clear stall failed, IOERROR Jan 19 19:41:31 kenshin kernel: umass0: BBB reset failed, IOERROR Jan 19 19:41:31 kenshin kernel: umass0: BBB bulk-in clear stall failed, IOERROR Jan 19 19:41:31 kenshin kernel: umass0: BBB bulk-out clear stall failed, IOERROR Jan 19 19:41:31 kenshin kernel: umass0: BBB reset failed, IOERROR Jan 19 19:41:31 kenshin kernel: umass0: BBB bulk-in clear stall failed, IOERROR Jan 19 19:41:31 kenshin kernel: umass0: BBB bulk-out clear stall failed, IOERROR Jan 19 19:41:31 kenshin kernel: umass0: BBB reset failed, IOERROR Jan 19 19:41:31 kenshin kernel: umass0: BBB bulk-in clear stall failed, IOERROR Jan 19 19:41:31 kenshin kernel: umass0: BBB bulk-out clear stall failed, IOERROR Jan 19 19:41:31 kenshin kernel: umass0: BBB reset failed, IOERROR Jan 19 19:41:31 kenshin kernel: umass0: BBB bulk-in clear stall failed, IOERROR Jan 19 19:41:31 kenshin kernel: umass0: BBB bulk-out clear stall failed, IOERROR Jan 19 19:41:31 kenshin kernel: (da0:umass-sim0:0:0:0): removing device entry Jan 19 19:41:31 kenshin kernel: Opened disk da0 -> 5 After this, FreeBSD panics. I havn't had time to get a full backtrace, but I'll send that once I get it. In the mean-time, is there any fix for the error I'm getting? Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Linux Emulation Panic
What exactly were you running? I use linux emulation on -CURRENT right now for mozilla and a few other packages, and havn't had any panics... you might have your kernel modules out of sync with your kernel. Ken On Mon, 13 Jan 2003, Chuck McCrobie wrote: > Two panics produced when using Linux emulation on a > machine CVSUP'ed two hours ago. Both very easy to > produce. Am I the only one running Linux emulation on > -current? Or is something wacked-ifed with this > machine? > > Thanks, > > Chuck McCrobie > [EMAIL PROTECTED] > > > > > 1. cd /usr/ports/emulators/linux_base ; make install > (hand-typed, sorry for typo's) > > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x2c > fault code = supervisor read, page not present > instruction pointer = 0x08:0xc4670534 > stack pointer = 0x10:0xdcb45c98 > frame pointer = 0x10:0xdcb45c9c > 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 = 1516 (glibc_post_upgrade) > kernel: type 12 trap, code=0 > Stopped at stackgap_init+0x14: mol 0x2c(%eax),%edx > > db> trace > stackgrap_init(dcv45cd0,c047d023,c4360c78,c4361540,dcb45ce0) > at stackgap_init+0x14 > linux_execve(c4361540,dcb45d10,dcb45cfc,dcb45d00,3) at > linux_execve+0x17 > syscall(2f,2f,2f,8048816,bfbfea50) at syscall+0x2aa > Xint0x80_syscall() at Xint0x80_syscall+0x1d > --- syscall (11, Linux ELF, linux_execve), > eip=0x80486c2, esp=0xbfbfea2c, ebp=0xbfbfea38 > > > 2. kldload linux ; /compat/linux/sbin/ldconfig > > > > > __ > Do you Yahoo!? > Yahoo! Mail Plus - Powerful. Affordable. Sign up now. > http://mailplus.yahoo.com > > 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
compile problem
I'm seeing this on a -CURRENT cvsupped around 4:30 AM EST on 1/11/03 cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../../.. -I../../../dev -I../../../contrib/dev/acpica -I../../../contrib/ipfilter -D_KERNEL -include opt_global.h -fno-common -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror ../../../kern/kern_sysctl.c ../../../kern/kern_sysctl.c: In function `ogetkerninfo': ../../../kern/kern_sysctl.c:1393: `VM_METER' undeclared (first use in this function) ../../../kern/kern_sysctl.c:1393: (Each undeclared identifier is reported only once ../../../kern/kern_sysctl.c:1393: for each function it appears in.) *** Error code 1 Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NVIDIA driver compilation failed
Only one, that driver wasn't meant to compile on -CURRENT. It's not even supported there. Ken On Thu, 2 Jan 2003, Nuzrin Yaapar wrote: > Hi all, > > With the latest CURRENT cvsupped today, NVIDIA driver failed to compile. The > output: > > --- > [root@zhang-wu-ji ~/NVIDIA]# make setup > ... > << snipped >> > cc -O -pipe -mcpu=pentiumpro -I/root/NVIDIA/module/../src -D__KERNEL__ > -DNV_MAJOR_VERSION=1 -DNV_MINOR_VERSION=0 -DNV_PATCHLEVEL=3203 -DNV_UNIX > -DNV_BSD -DNVCPU_X86 -D_KERNEL -Wall -Wredundant-decls -Wnested-externs > -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual > -fformat-extensions -ansi -DKLD_MODULE -nostdinc -I- > -I/root/NVIDIA/module/../src -I. -I@ -I@/dev -I@/../include -I/usr/include > -fno-common -mno-align-long-strings -mpreferred-stack-boundary=2 > -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes > -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions > -ansi -c /root/NVIDIA/module/../src/nvidia_subr.c > /root/NVIDIA/src/nvidia_subr.c: In function `nvidia_close_ctl': > /root/NVIDIA/src/nvidia_subr.c:317: dereferencing pointer to incomplete type > /root/NVIDIA/src/nvidia_subr.c: In function `nvidia_close_dev': > /root/NVIDIA/src/nvidia_subr.c:370: dereferencing pointer to incomplete type > *** Error code 1 > > Stop in /root/NVIDIA/module. > *** Error code 1 > > Stop in /root/NVIDIA. > Exit 1 > [root@zhang-wu-ji ~/NVIDIA]# > > --- > > Any pointers? > > __ > Do you Yahoo!? > Yahoo! Mail Plus - Powerful. Affordable. Sign up now. > http://mailplus.yahoo.com > > 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: Problem with nvidia drivers and current
> Just ran tuxracer without a problem, so i can recommend people with > problems to try using the nvidia agp driver, seems as if it worked for > me :) Haha, that's funny, it wouldn't work for most games using the nvidia driver for me, I had to switch to using FreeBSD's agpgart. Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: speed of -CURRENT [was: questions about the state of current]
> The systems hostname was changed between Aug & Oct, but it's the > same laptop, a P3-800 w/256MB memory. > > Thoughts? > I have not really noticed a performance difference here. In fact with WITNESS and INVARIANTS disabled, I find that -CURRENT seems to be a bit faster than -STABLE. Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: wierd cpu usage numbers
No, not really, I checked top -S, and systat -vm, neither has interrupts going high, but even if interrupts were going really high, I would suspect that the intr % would increase not the system % Ken On Thu, 17 Oct 2002, Michael Lucas wrote: > On Thu, Oct 17, 2002 at 11:18:25AM -0400, Kenneth Culver wrote: > > > This is a result of what's explained there. > > > > Nope, I have all that stuff turned off, and ide write caching turned on. > > There's no way that's the reason. > > OK, then, it's something else. :-) > > Does, say, top -S show any interrupts going awry? > > ==ml > > -- > Michael Lucas [EMAIL PROTECTED], [EMAIL PROTECTED] > http://www.oreillynet.com/pub/q/Big_Scary_Daemons > >Absolute BSD: http://www.AbsoluteBSD.com/ > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: wierd cpu usage numbers
> This is a result of what's explained there. Nope, I have all that stuff turned off, and ide write caching turned on. There's no way that's the reason. Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
wierd cpu usage numbers
Hi, I was just compiling kde3 on my home pc, and I noticed some interesting behavior. It seems that whenever there's ANY real heavy disk activity, the "system" cpu usage % number (in top and in systat -vm) skyrockets from 0.8% to around 50-70%. I was wondering which of the recent changes could have caused this... also in systat, the increase of the system % number seems to correspond with zfod, cow, and prcfr numbers jumping. Any ideas? Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ttys patch - any objections?
This seems a lot like personal preferance to me, I for one don't like a lot of tty's, because running getty on a bunch of ttys that I'm not going to use is a waste of ram I usually keep F1-F3 as ttys, and make F4 run kdm. I know I don't really have a say, but I'm sure everyone has his or her own preference. Ken On Thu, 26 Sep 2002, Mark Murray wrote: > Hi > > The attached patch gets done by me any time I set up a FreeBSD > box (I like lots of VTYs and X on ALT-F12). > > Any objections to my committing this? > > M > -- > o Mark Murray > \_ > O.\_Warning: this .sig is umop ap!sdn > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic in latest build
> Michael Hostbaek wrote:
> > I just build latest -CURRENT on my laptop.
> >
> > The error is:
> > panic: vrele: negative ref cnt
> > Debugger("panic")
> > Stopped at Debugger+0x54: xchgl %ebx,in_Debugger.0
> >
> > I did the following:
> > After bootup - logged in as root.
> > touch'ed /var/log/xferlog
> > and hit ctrl-d, to logout. (That is when the panic occured)
>
> I got a similar panic just following Jeff's rather complicated
> vfs kernel patches last night. I decided to wait and try again
> in a day or so to let the experts hash it out ;-)
>
>
Just as another data-point, I'm seeing this too.
Ken
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: current.freebsd.org points to japanese site?
Is there any difference between the snapshots built on the japanese site and the ones that were built on the US one? Thanks Ken On Sun, 22 Sep 2002, Will Andrews wrote: > On Sun, Sep 22, 2002 at 03:33:24PM -0400, Kenneth Culver wrote: > > Why does current.freebsd.org point to the japanese snapshot site > > snapshots.jp.freebsd.org? I'm just wondering because I am trying to > > install -CURRENT on one of my machines. > > Because it's the only reliable current snapshot building site? > > regards, > -- > wca > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
current.freebsd.org points to japanese site?
Why does current.freebsd.org point to the japanese snapshot site snapshots.jp.freebsd.org? I'm just wondering because I am trying to install -CURRENT on one of my machines. Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Softupdate panic: softdep_update_inodeblock: update failed
Oh ok, wierd... I've only tried (unsuccessfully, the compiler errors out) kde3, and some make worlds and stuff. I guess that's not strenuous enough. Ken On Thu, 12 Sep 2002, Martin Blapp wrote: > > Hi, > > > If I were you I'd start swapping memory modules, because I'm not having > > Already did that. I even used ECC ram. > > > any trouble with -CURRENT and I havn't seen anyone else having trouble. > > Did you try to build a huge project ? If I don't compile anything big > and load the machine it works perfectly. > > > Did you compile your kernel with any wierd optimizations? > > No. > > And this system works perfectly before after I turned on PG_G. > > The instability began after gcc3.2 import. > > Martin > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Softupdate panic: softdep_update_inodeblock: update failed
> I just got thisone ... This is CURRENT from 2 hours ago. > > Dammnit. Is this mem corruption ? > If I were you I'd start swapping memory modules, because I'm not having any trouble with -CURRENT and I havn't seen anyone else having trouble. Did you compile your kernel with any wierd optimizations? Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: SSE instructions (Re: cvs commit: src/share/mkbsd.cpu.mk)
> I assume the compiler is not stupid enough to try and use both when that > is impossible. Don't forget this is all just passing a CPU name to gcc > which actually decides what instructions to use. That's not what I mean... What I mean is that if one application is using SSE, and the other wants to use 3dnow, this will incur a performance penalty (although I'm not sure how much or how noticable it is), so some people may not want to have SSE enabled. Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: SSE instructions (Re: cvs commit: src/share/mkbsd.cpu.mk)
> Note that you'll need to have 'options CPU_ENABLE_SSE' in your kernel > configuration file if you have a SSE-capable CPU, otherwise you'll get > SIGILL from certain applications (e.g. ncurses) What if you don't want to do this though? Athlon XP processors support SSE instructions, but not at the same time as 3dnow instructions. The processor has to switch modes or something like that. What if a user wants to actually use the 3dnow instructions? Does this mean that on an athlon XP which supports SSE instructions, if you don't want to enable them you'll catch SIGILL and die when using those "certain apps?" Just wondering. Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: KDE broken on CURRENT (with gcc3.2)
> I'm the maintainer, Will. > > Since I don't have a -CURRENT system, is one of the hasta's set up to > test -CURRENT patches on? > > I can make a good guess at it from looking at the code, but it'll need > to be tested somewhere. > > Also, is gcc-3.2 on -CURRENT a supported configuration? > gcc-3.2 on -CURRENT is the compiler that is default. Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: KDE broken on CURRENT (with gcc3.2)
I can confirm that kde3 doesn't build on -CURRENT with gcc 3.2.1 as well, but it has never worked for me on gcc 3.1 either. Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Status of C++ in base system?
> The cerr not found thing is one of two problems. gcc3 is pickier > about namespace issues than gcc2, so you need to say std::cerr or > using namespace std;. However, the more common case is people > thinking they can link c++ programs with 'cc' rather than 'c++' > > My C++ programs are large enough that there are issues, but nothing > this trivial. Usually it is bad C++ that the newer compiler is > pickier about accepting. > Hrmm, maybe I'll try that too. Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Status of C++ in base system?
> In any case, the more verbose error reports are highly appreciated. > Could you please post the error messages you are getting (assuming your > next try of installworld with clean /usr/include does not help). Yeah, I can do that, the only reason I didn't do it this time is because my home pc is off and I'm at work, so I can't log in and mess with it. Ken > > On Thu, 11 Jul 2002 10:51:34 -0400 (EDT) > Kenneth Culver <[EMAIL PROTECTED]> wrote: > > > > This is FAQ. Have you deleted obsolete g++ include files? Do mv > > > /usr/include /usr/include.old; mkdir /usr/inlcude before making > > > buildworld. > > > > I think I did that but I guess another try couldn't hurt... > > > > Ken > > -- > Alexander Kabaev > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Status of C++ in base system?
> This is FAQ. Have you deleted obsolete g++ include files? Do mv > /usr/include /usr/include.old; mkdir /usr/inlcude before making > buildworld. I think I did that but I guess another try couldn't hurt... Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Status of C++ in base system?
I don't think kde3 compiles on the latest -CURRENT though, I've been trying to compile that for several days, and every time the linker says that things like cout and other standard c++ things aren't found. Ken On Wed, 10 Jul 2002, M. Warner Losh wrote: > I'm not sure what the deal with X is, but I have several non-X11 C++ > programs that work just fine. > > Warner > > 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: ipfw rule changes?
> Hi, I just updated this morning to the latest -CURRENT, and just to let > everyone know, the new KSE stuff seems to be working fine... however, my > ipfw rules for dummynet no longer work: > > ipfw add queue 1 tcp from any to a.b.c.d 25 in via fxp0 > ipfw pipe 1 config bw 28Kbit/s queue 2 > ipfw queue 1 config pipe 1 mask dst-ip 0x > > Am I doing something wrong here? This worked fine before I rebuilt world > (and I'm assuming rebuilt the ipfw program)... > Oh yeah, this is the error message: alpha:~:# ipfw queue 1 config pipe 1 mask dst-ip 0x ipfw: unrecognised option ``1'' Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ipfw rule changes?
Hi, I just updated this morning to the latest -CURRENT, and just to let everyone know, the new KSE stuff seems to be working fine... however, my ipfw rules for dummynet no longer work: ipfw add queue 1 tcp from any to a.b.c.d 25 in via fxp0 ipfw pipe 1 config bw 28Kbit/s queue 2 ipfw queue 1 config pipe 1 mask dst-ip 0x Am I doing something wrong here? This worked fine before I rebuilt world (and I'm assuming rebuilt the ipfw program)... Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: KSE status.
> I'm running a uniproc. box at work with -CURRENT and over 4-5hrs, wired > grew from 50megs (when I first time checked) to 141megs (now). Dunno if > this normal, but it has kept growing. OK, I don't see it happening here on my uniproc box, I havn't tried on my SMP box, I guess my sources aren't new enough. ;-) Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: KSE status.
Does this wired memory problem only happen on SMP systems, or is it happening across the board? Ken On Wed, 3 Jul 2002, Julian Elischer wrote: > > Well it's all fun and games her at KSE central.. > We have a set of cascading hidden bugs.. > > bug 1 hides bug 2 hides bug 3 > > the current state of play: > > the system works well for a while however there is a leak in > the system that gradually runs the system out memory. > the wired memory count grows with time. My test system presently has > 241MB of Wired memory out of a 512M system. > > This didn't affect systems before today because the code was hidden by > another bug.. > that wasn't evident because of another bug.. etc.. > still I think I am making progress. Just remember to reboot your system > whenever your wired memory gets too high :-) > > > > 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: GCC upgrade ? on -current
Is this not the latest one? alpha:~:> gcc -v Using built-in specs. Configured with: FreeBSD/i386 system compiler Thread model: posix gcc version 3.1 [FreeBSD] 20020509 (prerelease) Ken On Tue, 25 Jun 2002, Sid Carter wrote: > Hi, > > Just a query. Is there anything stopping us from moving to the > latest gcc on current ? Just curious. Cause mozilla won't compile with > gcc from current and I have installed gcc from the ports just for that. > > Thanks > Regards > Sid > -- > I've known him as a man, as an adolescent and as a child -- sometimes > on the same day. > > Sid Carter FreeBSD oder Debian GNU/Linux. > > 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: Please test PAUSE on non-Intel processors
I tested this on my T-bird athlon 800, and this is the result: Testing PAUSE instruction: Register esp changed: 0xbfbffb38 -> 0xbfbffafc So I guess there's no problem. Ken On Fri, 24 May 2002, John Baldwin wrote: > Hey gang, although Intel's document seems to claim that they tested > proper operation of pause I'd like people with non-Intel processors > to verify that it actually works. Please compile the attached test > program and run it. The output should look like this: > > > ./pt > Testing PAUSE instruction: > Register esp changed: 0xbfbff9fc -> 0xbfbff9c0 > > If you get a signal or any of the other registers change their value, > please let me know. I've tested this on a Pentium III mobile, a K6-II, > and an Athlon. The program cmopiles ok on both stable and current. > > -FW: <[EMAIL PROTECTED]>- > > Date: Tue, 21 May 2002 15:26:36 -0700 (PDT) > Sender: [EMAIL PROTECTED] > From: John Baldwin <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED], [EMAIL PROTECTED] > Subject: cvs commit: src/sys/kern kern_mutex.c > > jhb 2002/05/21 15:26:36 PDT > > Modified files: > sys/kern kern_mutex.c > Log: > Add appropriate IA32 "pause" instructions to improve performanec on > Pentium 4's and newer IA32 processors. The "pause" instruction has been > verified by Intel to be a NOP on all currently existing IA32 processors > prior to the Pentium 4. > > Revision ChangesPath > 1.95 +17 -1 src/sys/kern/kern_mutex.c > > --End of forwarded message- > > -- > > 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: linux-q3ademo --> X crash
It looks like DRI isn't set up right. Ken On Tue, 21 May 2002, Martin Kacerovsky wrote: > Hi. > I've installed linux-q3ademo to do some "benchmarking", but X server crashes > during startup... > X server gets signal 11, XFree86.1.log is included as attachement > > I haven't found solutions of this problem on the internet, only the same > questions. > Martin > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Save a few hunderd kilobytes or a few hundred perl users
> The base will no longer depend on it before too much longer. The vnode > and kobj dependencies are already gone in current. Ahh, ok, if that's the case, then I agree with your original statement; not that it matters much :-) Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Save a few hunderd kilobytes or a few hundred perl users?
But doesn't the kernel rely on perl for building? perl5 ../../kern/vnode_if.pl -h ../../kern/vnode_if.src does it make sense to remove it from the base when the base depends on it? Ken On Wed, 1 May 2002, M. Warner Losh wrote: > My take on this. We should remove perl from the base, and > automatically install the port for most users in sysinstall, just like > we do with XFree86. > > Warner > > 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: implementing linux mmap2 syscall
Alright, so I got tired of trying to figure out if glibc is doing something wierd or wrong so I downloaded the source for it, and I'm looking at it now... (for version 2.2.2 which is what we have on FreeBSD's linux_base-7) and here's what I'm seeing: pushl %ebp pushl %ebx pushl %esi pushl %edi movl OFFLO(%esp), %edx movl OFFHI(%esp), %ecx testl $0xfff, %edx jne L(einval) shrdl $12, %ecx, %edx /* mmap2 takes the offset in pages. */ shrl $12, %ecx jne L(einval) movl %edx, %ebp So above I'm seeing the offset arg get into register %ebp, which is what we expect... movl ADDR(%esp), %ebx movl LEN(%esp), %ecx movl PROT(%esp), %edx movl FLAGS(%esp), %esi movl FD(%esp), %edi Then I'm seeing all the other args getting put into the registers they belong in... (which matches up with our linux_prepsyscall() function) movl $SYS_ify(mmap2), %eax /* System call number in %eax. */ /* Do the system call trap. */ L(do_syscall): int $0x80 Now I'm seeing the int 0x80 trap /* Restore registers. */ popl %edi popl %esi popl %ebx popl %ebp So, as far as I can tell, this version of glibc is doing the Right Thing, and the ebp register is getting messed up somewhere along the line in either the assembly code that handles the 0x80 trap in FreeBSD, or in syscall2 (I think it's probably the asm that handles the 0x80 trap)... Can anyone confirm this? Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: implementing linux mmap2 syscall
> yeah, I did that already, and have been running with that since yesterday
> :-P
>
> still not working right though... I think it has something to do with that
> nargs thing... I'm checking that out now...
>
Ehh, apparently sy_narg is getting set correctly too:
struct linux_mmap2_args {
l_ulong addr; char addr_[PAD_(l_ulong)];
l_ulong len;char len_[PAD_(l_ulong)];
l_ulong prot; char prot_[PAD_(l_ulong)];
l_ulong flags; char flags_[PAD_(l_ulong)];
l_ulong fd; char fd_[PAD_(l_ulong)];
l_ulong pgoff; char pgoff_[PAD_(l_ulong)];
};
#define AS(name) (sizeof(struct name) / sizeof(register_t))
{ AS(linux_mmap2_args), (sy_call_t *)linux_mmap2 }
not that it really matters, the linux_prepsyscall is setting the params to
null:
static void
linux_prepsyscall(struct trapframe *tf, int *args, u_int *code, caddr_t
*params){
args[0] = tf->tf_ebx;
args[1] = tf->tf_ecx;
args[2] = tf->tf_edx;
args[3] = tf->tf_esi;
args[4] = tf->tf_edi;
args[5] = tf->tf_ebp;
*params = NULL; /* no copyin */
}
so the code in syscall2 will not even bother to try to copy in the args...
it just uses whatever linux_prepsyscall tells it to use, and completely
ignores nargs... at least as far as I can tell...
Ken
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: implementing linux mmap2 syscall
> RCS file: /home/ncvs/src/sys/i386/linux/linux_sysvec.c,v > retrieving revision 1.99 > diff -u -2 -r1.99 linux_sysvec.c > --- linux_sysvec.c 4 Apr 2002 17:49:46 - 1.99 > +++ linux_sysvec.c 24 Apr 2002 23:57:23 - > @@ -711,4 +711,5 @@ > args[3] = tf->tf_esi; > args[4] = tf->tf_edi; > + args[5] = tf->tf_ebp; > *params = NULL; /* no copyin */ > } > > Cheers, > -Peter > -- > Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] > "All of this is for nothing if we don't go to the stars" - JMS/B5 > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > > yeah, I did that already, and have been running with that since yesterday :-P still not working right though... I think it has something to do with that nargs thing... I'm checking that out now... Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: implementing linux mmap2 syscall
> Here's where it happens:
> sys/i386/linux/linux_sysvec.c
>
> static void
> linux_prepsyscall(struct trapframe *tf, int *args, u_int *code, caddr_t *params)
> {
> args[0] = tf->tf_ebx;
> args[1] = tf->tf_ecx;
> args[2] = tf->tf_edx;
> args[3] = tf->tf_esi;
> args[4] = tf->tf_edi;
> *params = NULL; /* no copyin */
> }
>
> You probably want to add:
> args[5] = tf->tf_ebp;
> so that it ends up in the syscallargs struct.
Yeah, I did that... it still doesn't work, tf_ebp isn't getting set... So
I'm thinking that either I have a glibc that's too old, or something else
is wrong...
>
> For FreeBSD syscalls, we copy this from the top of stack for the number of
> 32 bit words specified in the syscall table in i386/trap.c:
> if (params && (i = narg * sizeof(int)) &&
> (error = copyin(params, (caddr_t)args, (u_int)i))) {
> (narg comes from the syscall table).
>
OK, that gives me an idea...
Ken
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: implementing linux mmap2 syscall
> I'm actually still not seeing a match between what's in truss, and what's > in my printed-out args, but it seems to be working anyway... > Argh, it's not working again... It was working on an install of ms office, but it won't work on some old windows game.. (winex) and it's still not setting the last arg (or register properly): truss output: linux_mmap2(0x6543,0x10,0x3,0x11,0x9,0x6) = 1698889728 (0x6543) notice that the last arg is 0x6, that's the page offset... what the kernel prints for the same call: mmap2(0x6543, 1048576, 3, 0x0011, 9, 0) notice that they both have all the same values until you get to the last one... at which point the value is wrong... Apparently this only causes problems on some windows programs that one may try to execute, and not on others... So, where can I force this to get set? Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: implementing linux mmap2 syscall
> > > libc sets it before it enters the kernel. Then on kernel entry we save > > > ebp in the trapframe. > > > > So in the case of linux emulation, the glibc that we're using in the > > linux-ulator isn't setting it properly? I'm using the linux_base-7 port > > for this, so as far as I can tell, it should work... assuming linux_base-7 > > is meant to run on a linux-2.4.x kernel (or kernel that's emulating that). > > > > I may have screwed up my linux libs somehow or another too... could this > > be causing the behavior I'm seeing? > > > > Ken > > > > > OK, I removed the linux_base packages that I had on here, and made some > changes to the linux-ulator (added the arg[5] = tf->tf_ebp, and then > re-installed the linux_base-7.1 package, and now things are working... > winex is working fine now. :-) I'll clean up my changes to the > linux-ulator, and submit them as a pr. > I'm actually still not seeing a match between what's in truss, and what's in my printed-out args, but it seems to be working anyway... Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: implementing linux mmap2 syscall
> > libc sets it before it enters the kernel. Then on kernel entry we save > > ebp in the trapframe. > > So in the case of linux emulation, the glibc that we're using in the > linux-ulator isn't setting it properly? I'm using the linux_base-7 port > for this, so as far as I can tell, it should work... assuming linux_base-7 > is meant to run on a linux-2.4.x kernel (or kernel that's emulating that). > > I may have screwed up my linux libs somehow or another too... could this > be causing the behavior I'm seeing? > > Ken > > OK, I removed the linux_base packages that I had on here, and made some changes to the linux-ulator (added the arg[5] = tf->tf_ebp, and then re-installed the linux_base-7.1 package, and now things are working... winex is working fine now. :-) I'll clean up my changes to the linux-ulator, and submit them as a pr. Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: implementing linux mmap2 syscall
> libc sets it before it enters the kernel. Then on kernel entry we save > ebp in the trapframe. So in the case of linux emulation, the glibc that we're using in the linux-ulator isn't setting it properly? I'm using the linux_base-7 port for this, so as far as I can tell, it should work... assuming linux_base-7 is meant to run on a linux-2.4.x kernel (or kernel that's emulating that). I may have screwed up my linux libs somehow or another too... could this be causing the behavior I'm seeing? Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: implementing linux mmap2 syscall
> > Brandon S Allbery KF8NH writes: > > On Wed, 2002-04-24 at 10:41, Andrew Gallatin wrote: > > > Maybe the argument isn't where you expect it to be, but is there. > > > Can you make a test program which calls mmap2 with its 6th arg as > > > something unique like 0xdeadbeef? Then print out (in hex :) the trapframe > > > from the linux prepsyscall routine & see if you can find the deadbeef. > > > > My recollection is that beyond 5 arguments, a pointer to the remaining > > ones is passed. (But my recollection may be wrong and I don't wish to > > subject myself to the source cesspool at the moment) > > > > I think that's how it used to work. Apparently, they've changed it > recently and they now pass 6 args in registers. Eg, in the linux > kernel sources, old_mmap() fetches its args via copy_from_user(), > whereas the newer sys_mmap2() doesn't. > > Drew > Yep, according to the docs and source code I looked at in the linux kernel, the sixth arg is in the ebp register. I've looked all over the FreeBSD kernel and the linux emulator for the place that actually sets these, and unfortunately, due to my lack of asm coding knowledge, I can't find anything. Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: implementing linux mmap2 syscall
I tried printing out everything in the trapframe in hex and nothing looke remotely right. Ken On 24 Apr 2002, Brandon S Allbery KF8NH wrote: > On Wed, 2002-04-24 at 10:41, Andrew Gallatin wrote: > > Maybe the argument isn't where you expect it to be, but is there. > > Can you make a test program which calls mmap2 with its 6th arg as > > something unique like 0xdeadbeef? Then print out (in hex :) the trapframe > > from the linux prepsyscall routine & see if you can find the deadbeef. > > My recollection is that beyond 5 arguments, a pointer to the remaining > ones is passed. (But my recollection may be wrong and I don't wish to > subject myself to the source cesspool at the moment) > > -- > brandon s. allbery [os/2][linux][solaris][japh] [EMAIL PROTECTED] > system administrator [WAY too many hats][EMAIL PROTECTED] > electrical and computer engineeringKF8NH > carnegie mellon university ["better check the oblivious first" -ke6sls] > > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: implementing linux mmap2 syscall
> Kenneth Culver writes:
> > OK, I found another problem, here it is:
> >
> > static void
> > linux_prepsyscall(struct trapframe *tf, int *args, u_int *code, caddr_t
> > *params)
> > {
> >args[0] = tf->tf_ebx;
> >args[1] = tf->tf_ecx;
> >args[2] = tf->tf_edx;
> >args[3] = tf->tf_esi;
> >args[4] = tf->tf_edi;
> >*params = NULL; /* no copyin */
> > }
> >
> > Basically, linux_mmap2 takes 6 args, and this looks here like only 5 args are
> > making it in... I checked this because the sixth argument to linux_mmap2() in
> > truss was showing 0x6, but when I printed out that arg from the kernel, it
> > was showing 0x0. Am I correct here?
> >
> > Ken
>
> Yes. According to http://john.fremlin.de/linux/asm/, linux used to
> parse only 5 args but now it parses six. Try adding:
> args[5] = tf->tf_ebp;
>
> Drew
>
>
OK, I THINK I found what calls the actual kernel syscall handler, and
sets it's args first, but I'm not sure:
from linux_locore.s
NON_GPROF_ENTRY(linux_sigcode)
call*LINUX_SIGF_HANDLER(%esp)
lealLINUX_SIGF_SC(%esp),%ebx/* linux scp */
movlLINUX_SC_GS(%ebx),%gs
movl%esp, %ebx /* pass sigframe */
push%eax/* fake ret addr */
movl$LINUX_SYS_linux_sigreturn,%eax /* linux_sigreturn() */
int $0x80 /* enter kernel with args
*/
0: jmp 0b
ALIGN_TEXT
I think the stuff above copies the args, and whatnot, but I'm not really
sure where it does this exactly...
It calls LINUX_SIGF_HANDLER, which then calls %esp's sf_handler function.
That is where I draw a blank, I don't know which function this is calling,
and can't find where it's being set. I think this might be what I want to
change though. :-P
Does anyone who actually knows assembly have any ideas?
Ken
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: implementing linux mmap2 syscall
> > > > Basically, linux_mmap2 takes 6 args, and this looks here like only 5 args are > > > > making it in... I checked this because the sixth argument to linux_mmap2() in > > > > truss was showing 0x6, but when I printed out that arg from the kernel, it > > > > was showing 0x0. Am I correct here? > > > > > > > > Ken > > > > > > Yes. According to http://john.fremlin.de/linux/asm/, linux used to > > > parse only 5 args but now it parses six. Try adding: > > >args[5] = tf->tf_ebp; > > > > > I don't think that arg is there: > > > > Apr 23 10:36:13 ken /kernel: tf->tf_ebp = -1077938040 > > > > Ken > > My guess is that we're not doing something we should be doing in > int0x80_syscall in order to get that last arg. But I do not have > enough x86 knowledge to understand how the trapframe is constructed, > so I cannot tell what needs to be done. > > Perhaps somebody with more x86 fu can help. > > Sorry, Crap, I don't know what's going on either, I was just looking at the asm in src/sys/i386/i386/exception.s, but I'm not very good with asm either, Can anyone help? I'm cross-posting to -current since nobody on hackers or emulation is able to help. Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Lock order reversals in sys_pipe.c
On Sunday 24 March 2002 05:26 pm, you wrote: > The bento cluster is now running with WITNESS enabled to try and track > down some odd UMA lock corruption panics. Instead, it found the > following lock order reversal in sys_pipe.c overnight: > > Mar 24 07:31:44 gohan17 kernel: lock order reversal > Mar 24 07:31:44 gohan17 kernel: 1st 0xcf51aa80 pipe mutex @ > /local0/scratch/usr/src/sys/kern/sys_pipe.c:450 Mar 24 07:31:44 > gohan17 kernel: 2nd 0xcf88dadc process lock @ > /local0/scratch/usr/src/sys/kern/kern_sig.c:2093 Mar 24 07:32:12 > gohan10 kernel: lock order reversal > Mar 24 07:32:12 gohan10 kernel: 1st 0xd9a29dc0 pipe mutex @ > /local0/scratch/usr/src/sys/kern/sys_pipe.c:450 Mar 24 07:32:12 > gohan10 kernel: 2nd 0xd961addc process lock @ > /local0/scratch/usr/src/sys/kern/kern_sig.c:2093 Mar 24 07:32:57 > gohan12 kernel: lock order reversal > Mar 24 07:32:57 gohan12 kernel: 1st 0xd9423080 pipe mutex @ > /local0/scratch/usr/src/sys/kern/sys_pipe.c:450 Mar 24 07:32:57 > gohan12 kernel: 2nd 0xdaa704dc process lock @ > /local0/scratch/usr/src/sys/kern/kern_sig.c:2093 Mar 24 09:02:29 > gohan13 kernel: lock order reversal > Mar 24 09:02:29 gohan13 kernel: 1st 0xd99d6500 pipe mutex @ > /local0/scratch/usr/src/sys/kern/sys_pipe.c:450 Mar 24 09:02:29 > gohan13 kernel: 2nd 0xd971cddc process lock @ > /local0/scratch/usr/src/sys/kern/kern_sig.c:2093 > > Those source references are from a -current kernel from last night. > > Kris I think I found something similar as well, I also found a panic, but havn't had time to track it down. The panic doesn't occur with a kernel from march 13th, but occurs with the latest kernels. Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cdrecord for ATAPI burners available..
> It puts its stuff in /usr/local/bin > Wierd, for me it put everything in /opt/schily/blah... I hate it when people do that. :-) Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cdrecord for ATAPI burners available..
> Not that I know of, but I recently got permission to share the > (very limitted BTW) changes I did to cdrecord/cdrdao over a year > ago, and now that the infrastructure for using it is in both > -stable and -current, it seemed worthwhile to release it to > the unsuspecting world... > > Judging by the number of downloads already it is VERY popular :) > Yeah, I've downloaded it, however, I'm using gmake to try to build it, and while something compiles, I can't find where it actually puts anything, and when I do a gmake install, it doesn't install anything, at least not by the name of "cdrecord" Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cdrecord for ATAPI burners available..
> Oh yes, I forgot, there is also a cdrdao on: > > ftp://freebsd.dk/pub/ATA/cdrdao-1.1.5-ATA.tgz > > Again no CAM or atapicam needed :) > Is this a competition??? :-) Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATAPICAM
No it hasn't, there are still patches. Ken On Tue, 19 Mar 2002, Samuel Tardieu wrote: > Has the ATAPICAM patch entered the kernel sources already? I cannot > seem to find the option in LINT. > > Sam > -- > Samuel Tardieu -- [EMAIL PROTECTED] -- http://www.rfc1149.net/sam > > > 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: gcc -O broken in CURRENT
> That's odd, I've never had any mozilla problems. All I know is that it > doesn't crash on sites that Netscape crashes on (anything java) and for > me it runs much faster than netscape. It loads slower, but renders pages > much faster, and I tend to load my browser once per day, and just leave > it on. Anyway, this is way OT, so that was my last message about it. Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
