Re: 5.0/5.1: Installer does not find CD-ROM drive - even thoughit's booted off it
On Tue, Jun 10, 2003 at 09:19:08PM -0500, [EMAIL PROTECTED] wrote: FWIW - I have a Samsung SM-348 48x CD/DVD combo unit that works just fine under 5.1 (and 4.8): acd0: CD-RW SAMSUNG CDRW/DVD SM-348B at ata0-master PIO4 Yes, i have 48X SAMSUNG CD-ROM SC-148T, and it works fine under 5.1 and 4.8 Maybe only 52X Samsung SC-152 is broken for FreeBSD. On 10 Jun, Vitaly Markitantov wrote: On Mon, Jun 09, 2003 at 10:20:03PM +0200, Per von Zweigbergk wrote: Hello. I'm having difficulty with the ISO image of FreeBSD 5.1. The same problem also appeared in 5.0, but since 5.1 had come out, I decided to try that before reporting this bug. When booting the installer off the CD-ROM and doing a Standard install, you first get to the stage of partitioning a hard drive. Then you get to the stage where distributions are chosen. After that, it wants you to choose install media. I choose CD/DVD, and suddenly it says: No CD/DVD devices found! This is strange, since I clearly have been able to boot from it, and the boot loader seems to find it. On a whim, I also tried to choose Floppy for the install, but that didn't work either: No floppy devices found! This is more than strange. It's truly bizarre. In the boot loader it says: BIOS CD is cd0 BIOS drive A: is disk0 BIOS drive C: is disk1 And just before it dumps into /stand/sysinstall, I get: ata1-master: timeout waiting for interrupt ata1-master: ATAPI identify failed The system is new, and has had no OS installed on it previously. I have upgraded the BIOS to the latest version. Specifications: - Microstar 865PE Neo2 LS mother board - 3 x Intel 10/100 Desktop Adapter S cards. (Supported by the fxp driver) - Cheap Geforce 4 MX based AGP graphics card - Western Digital Special Edition 120 GB hard drive with 8 MB disk cache connected using the onboard ATA100 functionality. Master on the first IDE bus. - Samsung CD-ROM drive connected to the second IDE bus as Master. Only does ATA33 with the cables I use. Looks like Samsung 52X CD-ROM is broken for FreeBSD, i have this problem with this drive, when i replace it to Asus 52X CD-ROM, all works fine. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] -- Vitaly Markitantov mailto: [EMAIL PROTECTED] ___ [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
Ian Freislich wrote: Terry Lambert wrote: Short term, cd /usr/src/sbin/ipfw; make depend make all install ought to fix it. I tried that as well, but the new binary also dumps core, but works well with previous versions of the firewall. Even back as far as my kernel.working from May 7 2003. Bogus header files; specifically, netinet/ip_fw.h. Because you can't build world, you are compiling the ipfw program with the old system include files instead of the new ones. You may also be missing a cvs update on the ipfw sources themselves (specifically, ipfw2.c). No, it did compile ipfw2.c (r1.24). I also installed all new includes before I compiled ipfw and re-worlding to no avail. I figured an old kernel with a working firewall was better than a new kernel with no firewall. No. The problem is that you compiled ipfw2.c with the header /usr/include/netinet/ip_fw.h, and not /usr/src/netinet/ip_fw.h. The way you get the new header is to install it, and as you noticed, that doesn't work. Alternately, you can specify a CFLAGS=-I/usr/src, and it will get the header that matches your kernel. Since the buildworld is a simple fix (back out the changes to the .mk file before trying to build), you should do that, instead. -- Terry ___ [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
Ian Freislich wrote: Andre Guibert de Bruet wrote: Ian, The new ipfw binary will work with an up-to-date kernel. What you need to do is boot this new kernel and only then try out the new ipfw binary. That doesn't really explain why the new ipfw binary core dumped with the new kernel, but worked fine with old kernels. Now that I've removed BDECFLAGS, it seems that my buildworld will succeed and whatever it was that was broken that ipfw linked in (statically) will hopefully be fixed and all will be good in my land of -CURRENT, for the moment that is. It was the wrong header file; I said that before. When world is built, it uses the chroot installed header files that come from /usr/src/include; when you build an individual command in situ, it uses the old, stale, evil, nasty, bad, wrong header files from /usr/include. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ACPI Regression in -CURRENT?
Stijn Hoop wrote: This is due to the Dell laptops having an invalid ACPI table in the BIOS. The only way to avoid these messages is to tell FreeBSD ACPI to override the vendor supplied table with a correct one. Alternately, since Microsoft works just peachy with this thing, it's somewhat apparent that the Derefof() and Refof() can be implied by the types of the values being passed, and the ACPI table parsing code should be changed to work like Microsoft's does, at least until FreeBSD displaces the 70% marketshare and can dictate defacto implementation standards, where Intel can't. Yeah, I know that it's better to be correct than Microsoft compatible, but it's also better to work with hardware as shipped by vendors. Unless you think you can get Dell to rev their BIOS... -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Epson Perfection 1250 Photo USB scanner
On Wed, 11 Jun 2003, Martin Dieringer wrote: Date: Wed, 11 Jun 2003 01:51:12 +0200 (CEST) From: Martin Dieringer [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Epson Perfection 1250 Photo USB scanner Hi, I just got the Epson 1250 usb scanner working on -current by only including one line into sys/dev/usb/usbdevs My Epson Perfection 2450 Photo is working fine with generic -current an the addition of the following line to epson.conf: usb /dev/uscanner0 the line is: product EPSON 1250 0x010f Perfection 1250 Photo and I inserted it just after the 1240. sane has to be configured for plustek and /dev/uscanner0 and it should be a new version because the scanner could be damaged otherwise... So is this a bad hack or could it just be included in the system? And why does the scanner not work with usbd and an entry in /etc/usbd.conf (alway attaches ugen0)? I don't know yet whether it works for the transparency adapter... martin ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] Bye! Michael Reifenberger ^.*Plaut.*$, IT, R/3 Basis, GPS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Correct PCI suspend and resume operations [ was Re: cirrus ich3doesn't work after suspend to disk ]
Orion Hodson wrote: It looks like the pci configuration space state has been lost during the suspend and resume. This may be because the bus has removed power from the devices attached to it on suspend. I've been through a cross section of drivers this morning and some explicitly save and restore the PCI configuration state space and others don't. The former seems like the safest path in most cases. AFAICT, we don't common code for handling this and maybe there should be some rather than have each driver replicate this behaviour. I like this idea; are there driver-specific bits, or can it all be done at a higher level? If it can't, at least a means of recording the space the driver looks at or touches might be the ticket... -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
5.1 install failure
I´m booting 5.1 install in IBM x342 with floppies (because the thing does not seem to want to boot from the CD-ROM) and when sysinstall goes into probing devices, I get a message about / filesystem being full and I´m going nowhere without my init and then the kernel panics. Any ideas how to proceed? Pete ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Compaq and 5.1-RELEASE
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm trying to install 5.1-R onto a Compaq Amarda V300 series laptop. If I allow ACPI to be loaded, it hangs pretty quick right after trying to mount the memory disk. However, in safe mode, it works until during the unpacking/installing, I get a Fatal trap 12: page fault while in kernel mode fault virtual address = 0x1c fault code = supervisor write, page not present instruction pointer = 0x8:0xc02fb3c5 stack pointer = 0x10:0xcae09898 frame pointer = 0x10:0xcae098ac 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 = 36 (bufdaemon) trap number = 12 panic: page fault This is 100% reproducable. - -- ANTONY T CURTIS Tel: +44 (1635) 36222 Abacus Polar Holdings Ltd Fax: +44 (1635) 38670 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (FreeBSD) iD8DBQE+5t6aA98IbJ8osCYRAmAPAJ9hg6JZ0/kaI/edPptkWiviqxSiMQCgzVsE by5tCEa54Tyh7EhvZOzArLI= =3mUV -END PGP SIGNATURE- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: libevent for FreeBSD ?
David Leimbach wrote: Interesting. I don't believe it needs to be in the source tree. I am not saying its bad code or isn't useful... I just don't understand what it has to do with FreeBSD. Does any of the other base code need this library? If so it would already be there wouldn't it? It's like Java: a platform independent API for programmers to use in creating platform dependent code. You pay some performance penalty for using it instead of writing to native interfaces, and in return, you get some source level portability to platforms that you may or may not really be interested in running on at some point (perhaps far in the future). If you are using this, you probably aren't overly concerned with squeezing the last ounce of performance out of your application, and you probably are writing some program that has to run either in a lot of places, or has to be portable to an unknown deployment platform. And once the deployment platform is known, you will probably rewrite to the native interfaces anyway. This isn't to say it's not useful, just that its use has a fairly limited scope and application, IMO. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: fxp0: device timeout with 5.1BETA2
On Tue, Jun 10, 2003 at 02:08:54PM +0200, Markus Wennrich wrote: fxp0: device timeout I get these as well. Is it on irq9 by any chance, along with acpi0 ? No. It's on irc 11 device 8 (as dmesg states). All irqs in bios are set to 11 (factory default). ACPI is disabled. Ok, well that's a useful data point (for me anyway) since it means there's a problem with fxp losing interrupts that's not related to some other ACPI problems I've experienced, suggesting that it's therefore a fxp driver problem. I have the same problem here with a freshly cvsupped 5.1-CURRENT. The machine has two fxp-NICs and I get device timeouts with both of them (with acpi enabled or disabled, both the same, no change). See attached dmesg. Well, I got a little further: Until yesterday, my fxp's both hat irq 10, shared with the uhci-usb-controller. Everything worked fine. Since the cvsup, fxp0 uses irq 3 (shared with sio0) and fxp1 irq 10 (shared with uhci0), which didn't work. If I remove sio from my kernel-config, fxp0 works fine. But if I use the fxp1-device (dhclient or ifconfig) the machine freezes immediatly. Then I tried to also remove the usb-support, so the fxp1 has irq 10 soley for itself ... doesn't work. The machine still freezes. (I tried to pinpoint both irq's to irq 3 via device.hints (hint.fxp.1.irq=3) ... didn't worked.) Well ... at least I can use fxp0 if it has its irq soley for itself. But the machine still freezes, if I try to use fxp1. Any ideas what else I could try? I volunteer for debugging ;-) Bye, Markus -- Unix IS user friendly ... it's just selective about who its friends are. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Compaq and 5.1-RELEASE
Antony T Curtis wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm trying to install 5.1-R onto a Compaq Amarda V300 series laptop. If I allow ACPI to be loaded, it hangs pretty quick right after trying to mount the memory disk. However, in safe mode, it works until during the unpacking/installing, I get a Fatal trap 12: page fault while in kernel mode fault virtual address = 0x1c fault code = supervisor write, page not present This is a dead giveaway that soemone is dereferencing a NULL pointer looking for a structure member at offset 28 decimal. If it were a much larger number, it would mean that someone was getting a page not present error on a real address, one that had been mapped and no longer was, or one as a result of a processor bug. In general, this is most likely a real bug. Maybe someone with access to the build machine with a symboled kernel can tell you what lives at 0x8:0xc02fb3c5 (the instruction pointer at the time of the fault), which would tell you (well, tell *them*) where the problem is, so that they could fix it, or give you some type of workaround. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [solved] buildworld error
Hi all, On Tue Jun 10, 2003 at 07:50PM -0400, Garance A Drosihn wrote: At 9:42 PM +0200 6/10/03, Gordon Bergling wrote: Since I disable BDECFLAGS in /etc/make.conf this problem goes away. I don't know if this effects the build process in any other way. I had enable them around 4.5-RELEASE or so. ;) I'm not sure what you mean by that. Did you remove a line which had BDECFLAGS=...etc... or did you remove a line which said something like CFLAGS=$BDECFLAGS ? I comment out the BDECFLAGS lines in /etc/make.conf. The appendanting lines I comment out, too. If you mean the first one, that probably means some makefile has a reference to BDECFLAGS and it (probably) should not. best regards, Gordon -- There is no place like 127.0.0.1/8! ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ThinkPad T20 with 5.0R wakes up from halt -p
Hello Kevin, Kevin Oberman schrieb: It is possible that the latest BIOS update (released 30-Apr) and ACPI code will fix the problem, but I can't confirm anything. In any case, you should go to 5.1. It fixes many, many things! where did you find it? At IBM's site I found only version 1.21. from 1999. Did you mean that version? When you say Everything is quite ok, does that include suspend (S3)? I have no reports of that working on any T series ThinkPad. S3 works mostly fine. Ciao Oliver ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[-CURRENT tinderbox] failure on sparc64/sparc64
TB --- 2003-06-11 09:41:32 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2003-06-11 09:41:32 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-06-11 09:44:19 - building world TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make -B buildworld Rebuilding the temporary build tree stage 1: legacy release compatibility shims stage 1: bootstrap tools stage 2: cleaning up the object tree stage 2: rebuilding the object tree stage 2: build tools stage 3: cross tools stage 4: populating /home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/include stage 4: building libraries stage 4: make dependencies stage 4: building everything.. TB --- 2003-06-11 10:36:26 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC Kernel build for GENERIC started on Wed Jun 11 10:36:26 GMT 2003 Kernel build for GENERIC completed on Wed Jun 11 10:45:11 GMT 2003 TB --- 2003-06-11 10:45:11 - generating LINT kernel config TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/conf TB --- /usr/bin/make -B LINT TB --- 2003-06-11 10:45:11 - building LINT kernel TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make buildkernel KERNCONF=LINT Kernel build for LINT started on Wed Jun 11 10:45:12 GMT 2003 [...] cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -D_KERNEL -include opt_global.h -fno-common -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/vinum/vinumconfig.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -D_KERNEL -include opt_global.h -fno-common -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/vinum/vinumdaemon.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -D_KERNEL -include opt_global.h -fno-common -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/vinum/vinuminterrupt.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -D_KERNEL -include opt_global.h -fno-common -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/vinum/vinumio.c /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/vinum/vinumio.c: In function `write_volume_label': /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/vinum/vinumio.c:714: `LABELSECTOR' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/vinum/vinumio.c:714: (Each undeclared identifier is reported only once /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/vinum/vinumio.c:714: for each function it appears in.) *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/LINT. *** Error code 1 Stop in
kernel: lnc0: Missed packet -- no reviece buffer QWE
Hi Everyone, I'm in the process of hand building a FreeBSD 5.1 CURRENT #2 box. I now have a booting system that I can log onto and use, but my network interface does not work :-( I get lots of: kernel: lnc0: Missed packet -- no recieve buffer and the occasional kernel: lnc0: Device timeout -- resetting I really don't know what to look for, however there are a couple of things that may be related: 1) I have no swap 2) I have not configured anything in particular in /etc, just copied it from my build tree and added a fstab 3) /bin /boot /sbin and /usr are all RO I'm sure its probably under my nose, but I need someone to point out what it is :-) Thanks, Anthony -- To email me add [QWE] to the subject. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: libevent for FreeBSD ?
David Leimbach wrote: Interesting. I don't believe it needs to be in the source tree. I am not saying its bad code or isn't useful... I just don't understand what it has to do with FreeBSD. Does any of the other base code need this library? If so it would already be there wouldn't it? If Linux used it, it would be rather useful. Because it automatically choses the best event noticiation mechanism (kqueue, if available :), if Linux applications used it, they would automatically use kqueue on FreeBSD, with all the performance gains that entails. Dave On Tuesday, June 10, 2003, at 06:18 PM, Martin Blapp wrote: Hi, Has anybody seen this the recent NetBSD posting about libevent ? http://mail-index.netbsd.org/tech-userlevel/2003/06/08/.html What do you think about it ? Martin ___ [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] -- Daniel C. Sobral (8-DCS) Gerencia de Operacoes Divisao de Comunicacao de Dados Coordenacao de Seguranca VIVO Centro Oeste Norte Fones: 55-61-313-7654/Cel: 55-61-9618-0904 E-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Outros: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] You teach best what you most need to learn. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
adsl/pppoe no longer connecting on 5.1
On my previous FreeBSD version (5.0 April 21 snapshot), my ADSL/pppoe setup worked fine... as it always has all the way back to 4.x. Now having installed 5.1-RELEASE, with no other changes, ppp no longer can seeming no longer connect to my adsl modem. I've been struggling with this for days. Is anyone else experiencing this, or can anyone suggest any things to try? Again I say, my simple config has always worked for me, and i can't find any reason to suggest it shouldn't any longer. The modem is an OvisLink (I forget the model at the moment). It has built in routing/nat capabilities, but I never have used them in the past (preferring the control/flexibilty of doing it on on the gateway FreeBSD box). With the problems i've been having however, I've had to set up the modem to handle the PPPoE itself... it is still plugged into the same interface on the FreeBSD box, and when the default route is fixed up the FreeBSD box is on the net: so the modem seems to be functioning properly, and the cables and interfaces all communicate without problems. The stumbling block seems to be that FreeBSD's ppp can no longer detect carrier on the modem, and so fails. I have tried using set cd off and dedicated mode for ppp, but this just then fails at the next phase since it still can't seem to communicate with the modem. What i see in my ppp.log (lots of logging): Jun 11 07:36:58 bee ppp[9076]: Phase: Using interface: tun0 Jun 11 07:36:58 bee ppp[9076]: Phase: deflink: Created in closed state Jun 11 07:36:58 bee ppp[9076]: tun0: Command: default: ident user-ppp VERSION (built COMPILATIONDATE) Jun 11 07:36:58 bee ppp[9076]: tun0: Phase: PPP Started (interactive mode). Jun 11 07:37:00 bee ppp[9076]: tun0: Command: /dev/ttypb: dial dsl Jun 11 07:37:00 bee ppp[9076]: tun0: Command: dsl: set log Phase Chat LCP IPCP CCP tun command debug Jun 11 07:37:00 bee ppp[9076]: tun0: Command: dsl: set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 0.0.0.0 Jun 11 07:37:00 bee ppp[9076]: tun0: Command: dsl: set device PPPoE:xl0 Jun 11 07:37:00 bee ppp[9076]: tun0: Command: dsl: set authname [EMAIL PROTECTED] Jun 11 07:37:00 bee ppp[9076]: tun0: Command: dsl: set authkey Jun 11 07:37:00 bee ppp[9076]: tun0: Command: dsl: set dial Jun 11 07:37:00 bee ppp[9076]: tun0: Command: dsl: set login Jun 11 07:37:00 bee ppp[9076]: tun0: Command: dsl: enable lqr Jun 11 07:37:00 bee ppp[9076]: tun0: Command: dsl: set lqrperiod 5 Jun 11 07:37:00 bee ppp[9076]: tun0: Command: dsl: set speed sync Jun 11 07:37:00 bee ppp[9076]: tun0: Command: dsl: set cd 5 Jun 11 07:37:00 bee ppp[9076]: tun0: Command: dsl: set ctsrts off Jun 11 07:37:00 bee ppp[9076]: tun0: Command: dsl: add default HISADDR Jun 11 07:37:00 bee ppp[9076]: tun0: Debug: wrote -1: cmd = Add, dst = 0.0.0.0/0, gateway = 10.0.0.2 Jun 11 07:37:00 bee ppp[9076]: tun0: Phase: bundle: Establish Jun 11 07:37:00 bee ppp[9076]: tun0: Phase: deflink: closed - opening Jun 11 07:37:00 bee ppp[9076]: tun0: Debug: List of netgraph node ``xl0:'' (id 1) hooks: Jun 11 07:37:00 bee ppp[9076]: tun0: Debug: Found orphans - ethernet Jun 11 07:37:00 bee ppp[9076]: tun0: Debug: Connecting netgraph socket .:tun0 - [4]::tun0 Jun 11 07:37:00 bee ppp[9076]: tun0: Debug: Sending PPPOE_CONNECT to .:tun0 Jun 11 07:37:00 bee ppp[9076]: tun0: Debug: Found the following interfaces: Jun 11 07:37:00 bee ppp[9076]: tun0: Debug: Index 1, name xl0 Jun 11 07:37:00 bee ppp[9076]: tun0: Debug: Index 2, name rl0 Jun 11 07:37:00 bee ppp[9076]: tun0: Debug: Index 3, name lo0 Jun 11 07:37:00 bee ppp[9076]: tun0: Debug: Index 4, name tun0 Jun 11 07:37:00 bee ppp[9076]: tun0: Phase: deflink: Connected! Jun 11 07:37:00 bee ppp[9076]: tun0: Phase: deflink: opening - dial Jun 11 07:37:00 bee ppp[9076]: tun0: Chat: deflink: Dial attempt 1 of 1 Jun 11 07:37:00 bee ppp[9076]: tun0: Phase: deflink: dial - carrier Jun 11 07:37:00 bee ppp[9076]: tun0: Debug: Waiting for carrier Jun 11 07:37:03 bee last message repeated 4 times Jun 11 07:37:04 bee ppp[9076]: tun0: Phase: deflink: Disconnected! Jun 11 07:37:04 bee ppp[9076]: tun0: Phase: deflink: carrier - hangup Jun 11 07:37:04 bee ppp[9076]: tun0: Debug: deflink: Close monitoring the interface (tcpdump -e -i xl0 not ip) one can see: 07:47:59.950033 0:1:3:23:ee:f4 Broadcast 8863 32: PPPoE PADI [Host-Uniq UTF8] 07:48:01.949617 0:1:3:23:ee:f4 Broadcast 8863 32: PPPoE PADI [Host-Uniq UTF8] I'd post my config if it would help to see it; but most of it can be seen in the log above, and it's really very simple and always had worked, so i'm not sure it's relevant in this case. -- Tim Middleton | Cain Gang Ltd | I'd ha' been a better man all my life if [EMAIL PROTECTED] | www.Vex.Net | I'd known there were things like this. (CSL) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PCI bus numbering and orphaned devices
On Wed, 2003/06/11 at 01:16:50 +0200, Bernd Walter wrote: On Tue, Jun 10, 2003 at 03:34:36PM -0700, John-Mark Gurney wrote: M. Warner Losh wrote this message on Tue, Jun 10, 2003 at 08:27 -0600: : hdrtype = REG(PCIR_HEADERTYPE, 1); : This needs to be tested on that given hardware. : I don't know if REG will work as expected because it asks function 0, : which is disabled. : : I've reread John-Mark's last mail about the readable registers. : So - yes it should work. That's what inspired me. Also, I'd expected that we'd need some kind of tweaking to make it actually compile and be neat. Ok, attached is a patched I tried, but sad to say, this doesn't work out to well. I added a printf before and after the REG statement, and a boot with the kernel give this output: found- vendor=0x108e, dev=0x5000, revid=0x13 bus=0, slot=1, func=1 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0147, statreg=0x02a0, cachelnsz=16 (dwords) lattimer=0x50 (2400 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) about to read HEADERTYPE panic: trap: data access error cpuid = 0; Uptime: 1s panic: Assertion mtx_unowned(m) failed at ../../../kern/kern_mutex.c:956 cpuid = 0; Uptime: 1s panic: Assertion mtx_unowned(m) failed at ../../../kern/kern_mutex.c:956 cpuid = 0; Uptime: 1s the last three lines repeate for a while, but this is because of: psycho_read_config(...) [...] /* * The psycho bridge does not tolerate accesses to unconfigured PCI * devices' or function's config space, so look up the device in the * firmware device tree first, and if it is not present, return a value * that will make the detection code think that there is no device here. * This is ugly... */ if (reg == 0 ofw_pci_find_node(bus, slot, func) == 0) return (0x); Which obviously will fail if reg != 0 which we try to do when reading the PCIR_HEADERTYPE.. So, the question is, does other arch's do something nasty like this too? Should I change the check to just do ofw_pci_find_node? Is this why pciconf -r is returning 0x when reading the ebus and firewire parts of the SME2300BGA? Simply because it isn't in the ofw tree? Possible - in fact I was very surprised that a disabled device was not readable on some registers. We have a similar situation on alpha, where we get traps for reading non available devices. It's handled in that we tell the system to expect traps before accessing registers. This is done by reading with the badaddr function, which sets a flag for our trap handler so it can continue in case the device doesn't exist. badaddr() returns a flags which tells if reading was successfull. I don't have any data sheets or the PCI spec, so making heads or tails of this is going be hard. It's OK to get errors when reading locations that aren't available. Some chipsets nerver trap, others only trap for type2 access (behind Bridges) and some always trap. I don't have the standard handy, but from my reading of the Shanley book, it seems that for the vendor ID register, a host bridge is required to return 0x if no device is present. Loading this task off to the software is a bit annoying. There is no mention of other registers, so reading them in the probe might theoretically cause problems even on host bridges that handle the vendor ID register correctly. - Thomas -- Thomas Moestl [EMAIL PROTECTED] http://www.tu-bs.de/~y0015675/ [EMAIL PROTECTED] http://people.FreeBSD.org/~tmm/ PGP fingerprint: 1C97 A604 2BD0 E492 51D0 9C0F 1FE6 4F1D 419C 776C ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: adsl/pppoe no longer connecting on 5.1
On Wednesday 11 June 2003 13:53, T. Muddletin wrote: Well, does your DSL Provider really support IPV6 ? Actually for me it seems that you try to establish an ipv6 connection, which is rarley supported! On my previous FreeBSD version (5.0 April 21 snapshot), my ADSL/pppoe setup worked fine... as it always has all the way back to 4.x. Now having installed 5.1-RELEASE, with no other changes, ppp no longer can seeming no longer connect to my adsl modem. I've been struggling with this for days. Is anyone else experiencing this, or can anyone suggest any things to try? Again I say, my simple config has always worked for me, and i can't find any reason to suggest it shouldn't any longer. The modem is an OvisLink (I forget the model at the moment). It has built in routing/nat capabilities, but I never have used them in the past (preferring the control/flexibilty of doing it on on the gateway FreeBSD box). With the problems i've been having however, I've had to set up the modem to handle the PPPoE itself... it is still plugged into the same interface on the FreeBSD box, and when the default route is fixed up the FreeBSD box is on the net: so the modem seems to be functioning properly, and the cables and interfaces all communicate without problems. The stumbling block seems to be that FreeBSD's ppp can no longer detect carrier on the modem, and so fails. I have tried using set cd off and dedicated mode for ppp, but this just then fails at the next phase since it still can't seem to communicate with the modem. What i see in my ppp.log (lots of logging): Jun 11 07:36:58 bee ppp[9076]: Phase: Using interface: tun0 Jun 11 07:36:58 bee ppp[9076]: Phase: deflink: Created in closed state Jun 11 07:36:58 bee ppp[9076]: tun0: Command: default: ident user-ppp VERSION (built COMPILATIONDATE) Jun 11 07:36:58 bee ppp[9076]: tun0: Phase: PPP Started (interactive mode). Jun 11 07:37:00 bee ppp[9076]: tun0: Command: /dev/ttypb: dial dsl Jun 11 07:37:00 bee ppp[9076]: tun0: Command: dsl: set log Phase Chat LCP IPCP CCP tun command debug Jun 11 07:37:00 bee ppp[9076]: tun0: Command: dsl: set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 0.0.0.0 Jun 11 07:37:00 bee ppp[9076]: tun0: Command: dsl: set device PPPoE:xl0 Jun 11 07:37:00 bee ppp[9076]: tun0: Command: dsl: set authname [EMAIL PROTECTED] Jun 11 07:37:00 bee ppp[9076]: tun0: Command: dsl: set authkey Jun 11 07:37:00 bee ppp[9076]: tun0: Command: dsl: set dial Jun 11 07:37:00 bee ppp[9076]: tun0: Command: dsl: set login Jun 11 07:37:00 bee ppp[9076]: tun0: Command: dsl: enable lqr Jun 11 07:37:00 bee ppp[9076]: tun0: Command: dsl: set lqrperiod 5 Jun 11 07:37:00 bee ppp[9076]: tun0: Command: dsl: set speed sync Jun 11 07:37:00 bee ppp[9076]: tun0: Command: dsl: set cd 5 Jun 11 07:37:00 bee ppp[9076]: tun0: Command: dsl: set ctsrts off Jun 11 07:37:00 bee ppp[9076]: tun0: Command: dsl: add default HISADDR Jun 11 07:37:00 bee ppp[9076]: tun0: Debug: wrote -1: cmd = Add, dst = 0.0.0.0/0, gateway = 10.0.0.2 Jun 11 07:37:00 bee ppp[9076]: tun0: Phase: bundle: Establish Jun 11 07:37:00 bee ppp[9076]: tun0: Phase: deflink: closed - opening Jun 11 07:37:00 bee ppp[9076]: tun0: Debug: List of netgraph node ``xl0:'' (id 1) hooks: Jun 11 07:37:00 bee ppp[9076]: tun0: Debug: Found orphans - ethernet Jun 11 07:37:00 bee ppp[9076]: tun0: Debug: Connecting netgraph socket .:tun0 - [4]::tun0 Jun 11 07:37:00 bee ppp[9076]: tun0: Debug: Sending PPPOE_CONNECT to .:tun0 Jun 11 07:37:00 bee ppp[9076]: tun0: Debug: Found the following interfaces: Jun 11 07:37:00 bee ppp[9076]: tun0: Debug: Index 1, name xl0 Jun 11 07:37:00 bee ppp[9076]: tun0: Debug: Index 2, name rl0 Jun 11 07:37:00 bee ppp[9076]: tun0: Debug: Index 3, name lo0 Jun 11 07:37:00 bee ppp[9076]: tun0: Debug: Index 4, name tun0 Jun 11 07:37:00 bee ppp[9076]: tun0: Phase: deflink: Connected! Jun 11 07:37:00 bee ppp[9076]: tun0: Phase: deflink: opening - dial Jun 11 07:37:00 bee ppp[9076]: tun0: Chat: deflink: Dial attempt 1 of 1 Jun 11 07:37:00 bee ppp[9076]: tun0: Phase: deflink: dial - carrier Jun 11 07:37:00 bee ppp[9076]: tun0: Debug: Waiting for carrier Jun 11 07:37:03 bee last message repeated 4 times Jun 11 07:37:04 bee ppp[9076]: tun0: Phase: deflink: Disconnected! Jun 11 07:37:04 bee ppp[9076]: tun0: Phase: deflink: carrier - hangup Jun 11 07:37:04 bee ppp[9076]: tun0: Debug: deflink: Close monitoring the interface (tcpdump -e -i xl0 not ip) one can see: 07:47:59.950033 0:1:3:23:ee:f4 Broadcast 8863 32: PPPoE PADI [Host-Uniq UTF8] 07:48:01.949617 0:1:3:23:ee:f4 Broadcast 8863 32: PPPoE PADI [Host-Uniq UTF8] I'd post my config if it would help to see it; but most of it can be seen in the log above, and it's really very simple and always had worked, so i'm not sure it's relevant in this case. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To
Re: kernel: lnc0: Missed packet -- no reviece buffer QWE
On Wed, Jun 11, 2003 at 09:51:02PM +1000, Anthony Wyatt wrote: Hi Everyone, I'm in the process of hand building a FreeBSD 5.1 CURRENT #2 box. I now have a booting system that I can log onto and use, but my network interface does not work :-( I get lots of: kernel: lnc0: Missed packet -- no recieve buffer and the occasional kernel: lnc0: Device timeout -- resetting Can you send the the dmesg output and pciconf -v -l -- Tis a wise thing to know what is wanted, wiser still to know when it has been achieved and wisest of all to know when it is unachievable for then striving is folly. [Magician] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: imgact_gzip.c
On Sat, 2003-06-07 at 10:13, Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], David Yeske writes:
imgact_gzip.c seems to be pretty stale. Has anyone considered fixing this? If
this were fixed
then kldload() / linker_load_module() could deal with a gzipped .ko file, and
gzipped elf
executables would work also?
At least originally imgact_gzip.c was heavily a.out aware.
Interesting.
Making imgact_gzip elf-aware would not make the kernel capable of loading gzipped
modules,
only executables. There's a separate link_elf.c that the kernel uses for linking ELF
images
into itself (rather than activating ELF executables at exec() time, with imgact_elf)
I've been fiddling a little with compressed data in the kernel already, and was able
to hack together
a patch for link_elf pretty quickly. The quickly means that there's no boot loader
support, and the
gzip handling is quite braindamaged, extracting the entire zipped file into allocated
memory before
parsing the ELF structure. This is mainly because the ELF parsing bits of link_elf
assume they can
make random access to the file. It'd take a bit of rework to make it work with a
serial data stream.
The whole thing's very rough around the edges, but I can gzip most of
/boot/kernel/*.ko, and load
the gzipped versions.
I can polish this up, and/or add gzipped executable support, if there's any interest
in reviewing or
committing it.
The patch adds GZLOADER and INFLATE options for the kernel, removing GZIP (which
was
busted anyway, and considered inflate.c to be part of the ELF support, while it's
pretty much a
standalone decompressor.) There's a COMPAT_GZAOUT option added, but it's just as
bust as
GZIP was before.
EOE. Patch may crash your kernel, delete your data, make your cat unwell, etc.
Cheers,
Peter.Index: conf/files
===
RCS file: /pub/FreeBSD/development/FreeBSD-CVS/src/sys/conf/files,v
retrieving revision 1.791
diff -u -r1.791 files
--- conf/files 9 Jun 2003 19:25:06 - 1.791
+++ conf/files 11 Jun 2003 12:48:40 -
@@ -1011,7 +1011,7 @@
isofs/cd9660/cd9660_vnops.coptional cd9660
kern/imgact_elf.c standard
kern/imgact_shell.cstandard
-kern/inflate.c optional gzip
+kern/inflate.c optional inflate
kern/init_main.c standard
kern/init_sysent.c standard
kern/kern_acct.c standard
Index: conf/files.i386
===
RCS file: /pub/FreeBSD/development/FreeBSD-CVS/src/sys/conf/files.i386,v
retrieving revision 1.445
diff -u -r1.445 files.i386
--- conf/files.i386 31 May 2003 17:06:19 - 1.445
+++ conf/files.i386 11 Jun 2003 12:51:27 -
@@ -407,7 +407,7 @@
isa/syscons_isa.c optionalsc
isa/vga_isa.c optionalvga
kern/imgact_aout.c optionalcompat_aout
-kern/imgact_gzip.c optionalgzip
+kern/imgact_gzip.c optionalcompat_gzaout
libkern/divdi3.c standard
libkern/moddi3.c standard
libkern/qdivrem.c standard
Index: conf/options
===
RCS file: /pub/FreeBSD/development/FreeBSD-CVS/src/sys/conf/options,v
retrieving revision 1.393
diff -u -r1.393 options
--- conf/options18 May 2003 03:46:30 - 1.393
+++ conf/options11 Jun 2003 12:54:32 -
@@ -603,3 +603,8 @@
# options for hifn driver
HIFN_DEBUG opt_hifn.h
HIFN_RNDTEST opt_hifn.h
+
+# options for gzip/inflate related functionality
+INFLATEopt_inflate.h
+COMPAT_GZAOUT opt_gzaout.h
+GZLOADER opt_gzloader.h
Index: kern/link_elf.c
===
RCS file: /pub/FreeBSD/development/FreeBSD-CVS/src/sys/kern/link_elf.c,v
retrieving revision 1.73
diff -u -r1.73 link_elf.c
--- kern/link_elf.c 12 May 2003 15:08:10 - 1.73
+++ kern/link_elf.c 11 Jun 2003 13:24:50 -
@@ -28,6 +28,7 @@
#include opt_ddb.h
#include opt_mac.h
+#include opt_gzloader.h
#include sys/param.h
#include sys/systm.h
@@ -42,6 +43,10 @@
#include sys/vnode.h
#include sys/linker.h
+#ifdef GZLOADER
+#include sys/inflate.h
+#endif
+
#include machine/elf.h
#ifdef GPROF
#include machine/profile.h
@@ -98,9 +103,40 @@
#endif
} *elf_file_t;
+struct vnreader {
+ struct vnode *vnodep;
+ struct thread *thread;
+};
+
+#ifdef GZLOADER
+#define MAXGZPAGES (1024 * 1024 / PAGE_SIZE) // Allow modules up to 1MB (uncompressed)
+
+struct gzreader {
+ /* reading from gzipped file. */
+ int error;
+ struct vnode *vn;
+ unsigned char *inPage;
+ struct thread *td;
+ int inPageSize;
+ int inPageOffset;
+ off_t inFileOffset;
+ int inPageCount;
+
+ /* gzip context */
+ struct inflate inflator;
+
+
Re: adsl/pppoe no longer connecting on 5.1
On Wednesday 11 June 2003 13:53, T. Muddletin wrote: On my previous FreeBSD version (5.0 April 21 snapshot), my ADSL/pppoe setup worked fine... as it always has all the way back to 4.x. Now having installed 5.1-RELEASE, with no other changes, ppp no longer can seeming no longer connect to my adsl modem. I've been struggling with this for days. Are you sure you really have 5.1-RELEASE and not 5-CURRENT shortly after -RELEASE? There have been many other reports on pppoe related breakage with ppp in -CURRENT, but 5.1-RELEASE should work (at least it works fine for me). -- Michael Nottebrock \ KDE on FreeBSD \ ,ww \ --- \ ,wWWCybaWW_) \ http://freebsd.kde.org\ `WSheepW'free \ II II node pgp0.pgp Description: signature
Re: adsl/pppoe no longer connecting on 5.1
On Wed, 11 Jun 2003, Gerald Mixa wrote: On Wednesday 11 June 2003 13:53, T. Muddletin wrote: Well, does your DSL Provider really support IPV6 ? Actually for me it seems that you try to establish an ipv6 connection, which is rarley supported! On my previous FreeBSD version (5.0 April 21 snapshot), my ADSL/pppoe setup worked fine... as it always has all the way back to 4.x. Now having installed 5.1-RELEASE, with no other changes, ppp no longer can seeming no longer connect to my adsl modem. I've been struggling with this for days. Is anyone else experiencing this, or can anyone suggest any things to try? Yes, we had a discussion about this two or three days ago. You could cvsup to RELENG_5_1 which still has the working ppp and hope smeone is going to fix this on -CURRENT. Uli. +---+ |Peter Ulrich Kruppa| | - Wuppertal - | | Germany | +---+ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PCI bus numbering and orphaned devices
On Tue, 2003/06/10 at 16:41:44 -0700, John-Mark Gurney wrote: Thomas Moestl wrote this message on Wed, Jun 11, 2003 at 01:02 +0200: On Tue, 2003/06/10 at 15:34:36 -0700, John-Mark Gurney wrote: There's a similar problem with hme devices in some Netra models, and so far I have just ignored this because of the ugliness involved (there were patches floating around at one point, but I did not commit them). The real fix (and the way I wanted to implement things from the beginning) is to write an OFW PCI bus, analogous to the ACPI one. This is high on my list, waiting for time to become available :) Yikes, I just started looking at the acpi code, and there's a lot of code in it! There's much setup to be done that the firmware is too lazy to do for us. Is this why pciconf -r is returning 0x when reading the ebus and firewire parts of the SME2300BGA? Simply because it isn't in the ofw tree? Could be. We just cannot handle devices without firmware nodes - we don't know whether we can safely access them, cannot assign interrupts etc. Ok, the only problem is that is then we have the same problem the ACPI code does in that hot swapping cards would have a problem. Since it appears to me that the OFW tree doesn't get updated upon a swap. (At least the usb part of the tree doesn't.) We do not support hotplugging at the moment anyway. If a bridge driver would implement that in the future without using any firmware support however, it will then need to know everything information about the interrupt routing required for its devices if it cannot use the firmware for this. in that case, it can just prevent the ofw_pci bus from attaching to it (this will be easily possible). I'd hope that machines that support hot-plugging of PCI devices would have firmware methods available to support that though. Does this mean that we should eliminate most of the Sun specific pci bus drivers in favor of OFW specific ones like ACPI? or? No, it means introducing an OFW bus driver, which uses the firmware to enumerate the devices and to support interrupt routing. The bridge drivers would be mostly unaffected by this. The only problem with this approach is that it can change the device enumeration; I hope that the resulting one will be the same one that is printed on the boxen, so it should be advantageous for new installations, but a minor migration problem for old ones. I've got some code for this already, it just isn't done yet. - Thomas -- Thomas Moestl [EMAIL PROTECTED] http://www.tu-bs.de/~y0015675/ [EMAIL PROTECTED] http://people.FreeBSD.org/~tmm/ PGP fingerprint: 1C97 A604 2BD0 E492 51D0 9C0F 1FE6 4F1D 419C 776C ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PCI bus numbering and orphaned devices
In message: [EMAIL PROTECTED] Thomas Moestl [EMAIL PROTECTED] writes: : On Tue, 2003/06/10 at 16:41:44 -0700, John-Mark Gurney wrote: : Thomas Moestl wrote this message on Wed, Jun 11, 2003 at 01:02 +0200: : On Tue, 2003/06/10 at 15:34:36 -0700, John-Mark Gurney wrote: : There's a similar problem with hme devices in some Netra models, and : so far I have just ignored this because of the ugliness involved : (there were patches floating around at one point, but I did not commit : them). : : The real fix (and the way I wanted to implement things from the : beginning) is to write an OFW PCI bus, analogous to the ACPI one. This : is high on my list, waiting for time to become available :) : : Yikes, I just started looking at the acpi code, and there's a lot of : code in it! : : There's much setup to be done that the firmware is too lazy to do for : us. : :Is this why pciconf -r is returning 0x when reading the ebus :and firewire parts of the SME2300BGA? Simply because it isn't in :the ofw tree? : : Could be. We just cannot handle devices without firmware nodes - we : don't know whether we can safely access them, cannot assign interrupts : etc. : : Ok, the only problem is that is then we have the same problem the ACPI : code does in that hot swapping cards would have a problem. Since it : appears to me that the OFW tree doesn't get updated upon a swap. (At : least the usb part of the tree doesn't.) : : We do not support hotplugging at the moment anyway. If a bridge driver : would implement that in the future without using any firmware support : however, it will then need to know everything information about the : interrupt routing required for its devices if it cannot use the : firmware for this. in that case, it can just prevent the ofw_pci bus : from attaching to it (this will be easily possible). : I'd hope that machines that support hot-plugging of PCI devices would : have firmware methods available to support that though. We'll need to do so for the cardbus bridges. However, the interupt is routed to the bridge and has to be shared with the cardbus/pccard cards. : Does this mean that we should eliminate most of the Sun specific pci : bus drivers in favor of OFW specific ones like ACPI? or? : : No, it means introducing an OFW bus driver, which uses the firmware to : enumerate the devices and to support interrupt routing. The bridge : drivers would be mostly unaffected by this. : The only problem with this approach is that it can change the device : enumeration; I hope that the resulting one will be the same one that is : printed on the boxen, so it should be advantageous for new : installations, but a minor migration problem for old ones. : : I've got some code for this already, it just isn't done yet. So are you talking about doing something akin to the acpi bridge code or something else? Would this more properly be called a OFW PCI bus driver, or would the OFW 'bus' reach over into other busses to add children? Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
kernel compile now depends on /usr/include ?
I thought that including stuff from /usr/include in kernel code was bad style ? If it is, Should src/include/bitstring.h be repocopied to src/sys/sys/bitstring.h ? Alternatively, we need some makefile magic to cater for the following case: + set -e + P=/bang/somewhere + rm -rf /bang/somewhere + mkdir /bang/somewhere + cd /bang/somewhere + cvs -d /home/ncvs -Q -R co sys + cd sys/i386/conf + make LINT cat ../../conf/NOTES NOTES | sed -E -n -f ../../conf/makeLINT.sed LINT + config LINT [...] Kernel build directory is ../compile/LINT Don't forget to do a ``make depend'' + cd ../compile/LINT + make -s depend [...] === netgraph/bluetooth/l2cap === netgraph/bluetooth/socket /bang/somewhere/sys/netgraph/bluetooth/socket/ng_btsocket.c:44:23: bitstring.h: No such file or directory /bang/somewhere/sys/netgraph/bluetooth/socket/ng_btsocket_hci_raw.c:52:23: bitstring.h: No such file or directory /bang/somewhere/sys/netgraph/bluetooth/socket/ng_btsocket_l2cap_raw.c:51:23: bitstring.h: No such file or directory /bang/somewhere/sys/netgraph/bluetooth/socket/ng_btsocket_l2cap.c:52:23: bitstring.h: No such file or directory /bang/somewhere/sys/netgraph/bluetooth/socket/ng_btsocket_rfcomm.c:54:23: bitstring.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /bang/somewhere/sys/modules/netgraph/bluetooth/socket. *** Error code 1 Stop in /bang/somewhere/sys/modules/netgraph/bluetooth. *** Error code 1 Stop in /bang/somewhere/sys/modules/netgraph. *** Error code 1 Stop in /bang/somewhere/sys/modules. *** Error code 1 Stop in /bang/somewhere/sys/i386/compile/LINT. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel: lnc0: Missed packet -- no reviece buffer QWE
On Wed, Jun 11, 2003 at 09:51:02PM +1000, Anthony Wyatt wrote: Hi Everyone, I'm in the process of hand building a FreeBSD 5.1 CURRENT #2 box. I now have a booting system that I can log onto and use, but my network interface does not work :-( I get lots of: kernel: lnc0: Missed packet -- no recieve buffer and the occasional kernel: lnc0: Device timeout -- resetting I really don't know what to look for, however there are a couple of things that may be related: 1) I have no swap 2) I have not configured anything in particular in /etc, just copied it from my build tree and added a fstab 3) /bin /boot /sbin and /usr are all RO I'm sure its probably under my nose, but I need someone to point out what it is :-) I get this all the time on my FreeBSD 4.8-RELEASE system, which is a P75 with a lnc NIC. The man page does say this driver is one of the more verbose ones, and I think the message about no recieve buffer is just that the system cannot keep up with the incoming data, and so there is no buffer left. Certainly on my system doing NAT across lnc0 and sis0, the system uses 30-40% CPU just to act as a router! I still get 600KB/s through it, which I have heard is fairly reasonable from a 10Mbit ISA network card. -- Bruce Cran ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
ACPI problems on 5.1-RELEASE
Howdy list, What info do I need to provide, and who do I need to send it to, so that I can get ACPI into a usable state on my IBM A30p thinkpad? The short description of my acpi problems is that I can suspend the laptop with 'acpiconf -s 3', but not with 'acpiconf -s 1', and the laptop never comes back from suspend properly. I have to power down the machine. When I first installed FreeBSD 5.1-Release on this laptop, I could get battery status info out of the 'apm' command, but now it isn't working for some reason. The following are true if the laptop is on battery or mains: apm -l = -1 apm -t = -1 apm -b = 3 apm -a = 1 'apm -b' yields '3', so I assume 'apm' thinks the battery is always charging... My gzipped dmesg.boot is attached. -- Jesse Guardiani, Systems Administrator WingNET Internet Services, P.O. Box 2605 // Cleveland, TN 37320-2605 423-559-LINK (v) 423-559-5145 (f) http://www.wingnet.net ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ThinkPad T20 with 5.0R wakes up from halt -p
Date: Wed, 11 Jun 2003 12:47:33 +0200 From: Oliver Fischer [EMAIL PROTECTED] Hello Kevin, Kevin Oberman schrieb: It is possible that the latest BIOS update (released 30-Apr) and ACPI code will fix the problem, but I can't confirm anything. In any case, you should go to 5.1. It fixes many, many things! where did you find it? At IBM's site I found only version 1.21. from 1999. Did you mean that version? This is a bit odd, but version IYET60WW shows a BIOS date in 12/99, but a release date of 30-Apr-2003. I have been told by others that is really is a new release. You probably should check your BIOS version against IYET60WW. When you say Everything is quite ok, does that include suspend (S3)? I have no reports of that working on any T series ThinkPad. S3 works mostly fine. Cool. On every ThinkPad I know of, ACPI S3 results in two problems. The disk spin down immediately, not allowing time for cache to flush (ouch!) and the backlight on the display stays on. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CardBus USB 2.0 Controller (NEC uPD)
* Craig Boston ([EMAIL PROTECTED]) wrote: I recently purchased a generic CompUSA branded CardBus USB 2.0 controller for a challenge to try to get it to work under FreeBSD ;) It appears to use an NEC chip -- one that I've seen reports of the PCI version working -- so at least some of the support for it is already there. I'm willing to take a stab at it and would be grateful if someone can point me in the general direction of where to start. Here's the dmesg output when it's attached. [snip dmesg] cardbus1: serial bus, USB at device 0.2 (no driver attached) That output seems a little funny, between the Resource not specified in CIS and claiming there is no driver attached right after it attaches ohci... Only the USB1.1 part of the card has been attached. You need to have 'device ehci' in your kernel config for it to pick up the USB2.0 part which will then get attached. If I plug something in to the other port the addr 0 should never happen! shows up on port 1 of usb1. After about 20 seconds or so I get the message uhub1: device problem, disabling port 1. I get the same message as you with what seems to be a generic NEC USB card. I haven't tried removing/reinserting the card so I can't tell you if my laptop panics in the same way as your machine. -- LJ : http://www.livejournal.com/users/everlone GPG/PGP: 6FA19F58 (http://wwwkeys.pgp.net) NP: pgp0.pgp Description: PGP signature
Makefile.yp aka /var/yp/Makefile.dist
Just as a precaution, does anyone have any objections to my removing
of these funny $^ sequences from Makefile.yp? They were apparently
used to insert something into the map generation pipeline just before
the yp_mkdb(8) invokation, but recent additions to this file did not
follow this rule.
Partial patch is attached.
Cheers,
--
Ruslan Ermilov Sysadmin and DBA,
[EMAIL PROTECTED] Sunbay Software Ltd,
[EMAIL PROTECTED] FreeBSD committer
Index: Makefile.yp
===
RCS file: /home/ncvs/src/usr.sbin/ypserv/Makefile.yp,v
retrieving revision 1.34
diff -u -r1.34 Makefile.yp
--- Makefile.yp 21 Mar 2003 11:44:03 - 1.34
+++ Makefile.yp 11 Jun 2003 17:40:23 -
@@ -235,7 +235,7 @@
ypservers: $(YPSERVERS)
@echo Updating [EMAIL PROTECTED]
$(CAT) $(YPSERVERS) | \
- $(AWK) '{ if ($$1 != $$1 !~ ^#.*) print $$0\t$$0 }' $^ \
+ $(AWK) '{ if ($$1 != $$1 !~ ^#.*) print $$0\t$$0 }' \
| $(DBLOAD) -i $(YPSERVERS) -o $(YPMAPDIR)/$@ - $(TMP); \
$(RMV) $(TMP) $@
@$(DBLOAD) -c
@@ -249,7 +249,7 @@
.else
$(CAT) $(ETHERS) | \
$(AWK) '{ if ($$1 != $$1 !~ ^#.* $$1 != +) \
- print $$2\t$$0 }' $^ | $(DBLOAD) -i $(ETHERS) \
+ print $$2\t$$0 }' | $(DBLOAD) -i $(ETHERS) \
-o $(YPMAPDIR)/$@ - $(TMP); $(RMV) $(TMP) $@
@$(DBLOAD) -c
@if [ ! $(NOPUSH) ]; then $(YPPUSH) -d $(DOMAIN) $@; fi
[...]
pgp0.pgp
Description: PGP signature
Re: kernel compile now depends on /usr/include ?
On Wed, Jun 11, 2003 at 04:38:53PM +0200, Poul-Henning Kamp wrote: I thought that including stuff from /usr/include in kernel code was bad style ? Yes, src/sys/ should be self-hosted. If it is, Should src/include/bitstring.h be repocopied to src/sys/sys/bitstring.h ? Yes please. Then a compatibility symlink could be made from /usr/include/bitstring.h to /usr/include/sys/bitstring.h. Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software Ltd, [EMAIL PROTECTED] FreeBSD committer pgp0.pgp Description: PGP signature
accessing smbfs volume using nautilus
I've got a new install of FreeBSD 5.1-RELEASE, and have installed gnome 2.2.1. Using Nautilus I access a volume mounted using smbfs. The files display correctly, but I get loads of messages: smb_maperror: Unmapped error 1:158 on the console, and accessing the files seems very slow. Is this a bug, or am I missing some mount_smbfs option? -- Bruce Cran ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: adsl/pppoe no longer connecting on 5.1
Gerald wrote on Wednesday, June 11, 2003, 9:43:02 AM: Well, does your DSL Provider really support IPV6 ? Actually for me it seems that you try to establish an ipv6 connection, which is rarley supported! That is interesting; I can't see where it appears to be this though. Perhaps something in (cryptic to me) the tcpdump message indicates this? Maybe this is the problem that CURRENT is having in general, if suddenly the client has switched everyone to ipv6. 07:47:59.950033 0:1:3:23:ee:f4 Broadcast 8863 32: PPPoE PADI [Host-Uniq UTF8] 07:48:01.949617 0:1:3:23:ee:f4 Broadcast 8863 32: PPPoE PADI [Host-Uniq UTF8] ? -- Tim Middleton | Cain Gang Ltd | But the trouble was that my hysterical fit [EMAIL PROTECTED] | www.Vex.Net | could not go on for ever. --Dost (NFTU) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CardBus USB 2.0 Controller (NEC uPD)
On Wed, 2003-06-11 at 17:08, Alistair Sutton wrote: [snip dmesg] cardbus1: serial bus, USB at device 0.2 (no driver attached) That output seems a little funny, between the Resource not specified in CIS and claiming there is no driver attached right after it attaches ohci... Only the USB1.1 part of the card has been attached. You need to have 'device ehci' in your kernel config for it to pick up the USB2.0 part which will then get attached. Thanks, I figured that out shortly after sending the message and doing some more googling (and smacked myself on the head -- for some odd reason I had the idea that ehci == firewire). Didn't want to clutter up the list with replying to myself over that point though :) It does attach ehci now and recognizes ohci0/1 as the supporting devices, but it has the same behavior on connecting things. The only difference is that if it's a USB 2.0 device, the addr 0 should never happen! shows up on the ehci controller rather than the ohci. I get the same message as you with what seems to be a generic NEC USB card. I haven't tried removing/reinserting the card so I can't tell you if my laptop panics in the same way as your machine. From what I can tell from usb_*_debug, it sees a device get plugged in and appears to think it's talking to it, but keeps timing out waiting for a response. I have no way to tell if it's actually sending anything over the wire or not. My money is still on a problem within the cardbus layer -- possibly I have some wonky hardware. I can provoke the following behavior by attaching a cardbus NIC (which works perfectly on its own) in conjunction with the USB card. *** USB card is already in, inserting NIC: xl0 attaches and works fine usb3: unrecoverable error, controller halted usb3: blocking intrs 0x10 uhub3: illegal enable change, port 1 usb3: port reset timeout uhub3: port 1 reset failed (sometimes it completely detaches the usb devices too, but not always) *** NIC already in, inserting USB card: ohci0 and ohci1 attach OK EHCI thinks that it's version ff.ff EHCI thinks it has 15 (!) companion devices and complains because (15 != 2) ehci0: USB init failed err=13 cardbus1: release_all_resource: Resource still owned by child, oops. About 50% of the time it panics in ehci_intr1, or sometimes pci_free_something (don't remember off the top of my head, sorry). Frustratingly, the behavior seems to be somewhat non-deterministic. For reference, my controller is cbb0: TI1450 PCI-CardBus Bridge I'm going to try to get a setup for a remote gdb connection and single-step through the attach code to attempt to get a better idea of what's going on. Not sure if I'll be able to figure it out or not. I have a relatively good understanding into the workings of ISA/PCI, but Cardbus is still a mystery to me. Craig ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ACPI Regression in -CURRENT?
+ Stijn Hoop [EMAIL PROTECTED]: | Hi Thorsten, | | On Tue, Jun 10, 2003 at 03:42:18PM +0200, Thorsten Greiner wrote: | some time ago several people (including me) reported ACPI related problems | on various Dell laptops resulting in error messages of the form | | ACPI-0293: *** Warning: Buffer created with zero length in AML | | During the 5.1 release process these problems have been temporarily fixed. | | This is due to the Dell laptops having an invalid ACPI table in the BIOS. | The only way to avoid these messages is to tell FreeBSD ACPI to override | the vendor supplied table with a correct one. | | Mark Santcroos developed a patch which worked on his C640 and my Inspiron | 4150, which you can find attached. Here are the steps to use it: [...] I tried that on my Inspiron 4150 with 5.1-RELEASE. The patch failed, but only for trivial reasons like different placment of braces. So I applied it by hand and followed directions, but the warning messages did not go away. I know my efforts did *something* though, as I find this in dmesg output: Preloaded acpi_dsdt /boot/acpi_dsdt.aml at 0xc055c1cc. [...] ACPI: DSDT was overridden. ACPI-0375: *** Info: Table [DSDT] replaced by host OS Also, I still cannot suspend the machine: acpiconf -s number results in a variety of interesting behaviour, always ending with the machine in a useless state (except acpiconf -s 5, which does what it should - like halt -p). Actually, acpiconf -s 3 seems to almost work: The screen goes blank, and the machine turns itself off - only to turn back on immediately, but with the screen remaining blank. So I hit Fn-F8 a couple of times, and lo and behold the screen is alive again and the machine is responsive once more. I did this from a console, but when I do Ctrl-Alt-F9 the X server is hosed: Wrong colours, garbage in the top of the screen, and zero response to any keypresses. Can you suspend yours? Any more clever tricks? (Hmm, I suppose we should discuss this on -mobile, but since the thread started here...) - Harald ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: adsl/pppoe no longer connecting on 5.1
Michael wrote on Wednesday, June 11, 2003, 10:02:25 AM: Are you sure you really have 5.1-RELEASE and not 5-CURRENT shortly after -RELEASE? There have been many other reports on pppoe related breakage with ppp in -CURRENT, but 5.1-RELEASE should work (at least it works fine for me). I definitely have -RELEASE... i'm working from the downloaded released ISO image. And it definitely says RELEASE on boot up (from dmesg): FreeBSD 5.1-RELEASE #0: Thu Jun 5 02:55:42 GMT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC (Though i have since recompiled the kernel using the sources on the CD-Rom -- i also recompiled src/usr.sbin/ppp at some point yesterday in one of my many failed attempts to fix the thing... but it didn't help... incidentally 'make buildworld' failed on a missing krb5.h ... but that's another issue...) -- Tim Middleton | Cain Gang Ltd | Then suddenly, for no apparent reason, the [EMAIL PROTECTED] | www.Vex.Net | unpitying orchestra struck up a polka. -D ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
BDECFLAGS being added to CFLAGS and CWARNFLAGS ( was Re: [solved]buildworld error)
From: Munehiro Matsuda [EMAIL PROTECTED]
I was having the same compile error, until I commeted out the
BDECFLAGS definition from /etc/make.conf.
Looking into the problematic Makefiles, I've found that following
Makefiles do references BDECFLAGS, which matches errors I was getting:
usr.sbin/config/Makefile : CFLAGS+= ${BDECFLAGS}
usr.sbin/lpr/Makefile.inc: CWARNFLAGS= ${BDECFLAGS}
usr.sbin/kgzip/Makefile : CFLAGS+= ${BDECFLAGS}
I think these references must be removed.
I did a find for BDECFLAGS and it found 5 Makefiles that are adding these
flags to either CFLAGS or CWARNFLAGS.
# cd /usr/src
# find . -type f -exec grep -H BDECFLAGS {} +
./sbin/ffsinfo/Makefile:#CFLAGS+=${BDECFLAGS}
./sbin/growfs/Makefile:#CFLAGS+=${BDECFLAGS}
:
./usr.sbin/config/Makefile:CFLAGS+= ${BDECFLAGS}
./usr.sbin/lpr/Makefile.inc:CWARNFLAGS= ${BDECFLAGS}
./usr.sbin/kgzip/Makefile:CFLAGS+= ${BDECFLAGS}
A couple of possible fixes are:
1. removal of BDECFLAGS from the above files
2. Add a .ifdef USE_BDECFLAGS .. .endif, that conditionalizes the use of
BDECFLAGS in the above files.
Scot
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PCI bus numbering and orphaned devices
On Wed, Jun 11, 2003 at 04:26:27PM +0200, Thomas Moestl wrote: On Tue, 2003/06/10 at 16:41:44 -0700, John-Mark Gurney wrote: Ok, the only problem is that is then we have the same problem the ACPI code does in that hot swapping cards would have a problem. Since it appears to me that the OFW tree doesn't get updated upon a swap. (At least the usb part of the tree doesn't.) We do not support hotplugging at the moment anyway. If a bridge driver would implement that in the future without using any firmware support however, it will then need to know everything information about the interrupt routing required for its devices if it cannot use the firmware for this. in that case, it can just prevent the ofw_pci bus from attaching to it (this will be easily possible). I'd hope that machines that support hot-plugging of PCI devices would have firmware methods available to support that though. I have no clue about cardbus, but for PCI hotplugging you need hardware specific support to power down the slots. But hotplug PCI is not a realm of specific machines, as you can attach add-on hotplug frames to any PCI system. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CardBus USB 2.0 Controller (NEC uPD)
On Tue, Jun 10, 2003 at 10:51:10AM -0500, Craig Boston wrote: I recently purchased a generic CompUSA branded CardBus USB 2.0 controller for a challenge to try to get it to work under FreeBSD ;) It appears to use an NEC chip -- one that I've seen reports of the PCI version working -- so at least some of the support for it is already there. I'm willing to take a stab at it and would be grateful if someone can point me in the general direction of where to start. There are known problems with USB2.0 cardbus cards. We have some kind of resource problem - Warner already wrote something about it some time ago. If I pop out the card I get: Neither OHCI nor EHCI controllers have working detach code right now. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: LG 5350 cell phone
I have this phone myself. I have two adapters for it -- one is a serial cable the other a true (as in no serial to usb conversion box in the middle) usb cable. The phone works great under FreeBSD on the serial cable (normal Hayes modem type at commands work fine), but no version of FreeBSD has worked with the usb cable so far. I tried 4.8, 5.0-RELEASE, and a few versions of 5.x-CURRENT. The phone is quite usable from my iBook so the cable isn't the issue (the iBook reports it as a Qualcomm -- which is what the sticker says too). I see the message you do, but when I try to use umodem with it the phone continuously reboots itself until detached. I tried something along the lines of what you did to usbdevs a while back but didn't get any improvement. The connection is appreciably faster over the usb port with the true cable when compared to the serial cable; it would be very nice to use it this way on FreeBSD... Sean ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: BDECFLAGS being added to CFLAGS and CWARNFLAGS ( was Re:[solved] buildworld error)
At 2:29 PM -0500 6/11/03, Scot W. Hetzel wrote:
From: Munehiro Matsuda [EMAIL PROTECTED]
I was having the same compile error, until I commeted out
the BDECFLAGS definition from /etc/make.conf.
Looking into the problematic Makefiles, I've found that
following Makefiles do references BDECFLAGS, which matches
errors I was getting:
usr.sbin/config/Makefile : CFLAGS+= ${BDECFLAGS}
usr.sbin/lpr/Makefile.inc: CWARNFLAGS= ${BDECFLAGS}
usr.sbin/kgzip/Makefile : CFLAGS+= ${BDECFLAGS}
I think these references must be removed.
Ugh. Every time there's a scan for some bad-programming
practice, 'lpr' is one of the guilty parties... I'll fix
that one!
I did a find for BDECFLAGS and it found 5 Makefiles that
are adding these flags to either CFLAGS or CWARNFLAGS.
# cd /usr/src
# find . -type f -exec grep -H BDECFLAGS {} +
./sbin/ffsinfo/Makefile:#CFLAGS+=${BDECFLAGS}
./sbin/growfs/Makefile:#CFLAGS+=${BDECFLAGS}
:
./usr.sbin/config/Makefile:CFLAGS+= ${BDECFLAGS}
./usr.sbin/lpr/Makefile.inc:CWARNFLAGS= ${BDECFLAGS}
./usr.sbin/kgzip/Makefile:CFLAGS+= ${BDECFLAGS}
A couple of possible fixes are:
1. removal of BDECFLAGS from the above files
2. Add a .ifdef USE_BDECFLAGS .. .endif, that
conditionalizes the use of BDECFLAGS in the
above files.
Ick. Then we'll need a USE_USE_BDECFLAGS, to tell us if we
should pay attention to the USE_BDECFLAGS variable...
My guess is that there isn't a single reason that these five
programs need to reference BDECFLAGS, especially now that it
is no longer defined in /etc/defaults/make.conf . We should
just remove those references.
--
Garance Alistair Drosehn= [EMAIL PROTECTED]
Senior Systems Programmer or [EMAIL PROTECTED]
Rensselaer Polytechnic Instituteor [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ACPI Regression in -CURRENT?
On Wed, Jun 11, 2003 at 08:18:26PM +0200, Harald Hanche-Olsen wrote: + Stijn Hoop [EMAIL PROTECTED]: | Hi Thorsten, | | On Tue, Jun 10, 2003 at 03:42:18PM +0200, Thorsten Greiner wrote: | some time ago several people (including me) reported ACPI related problems | on various Dell laptops resulting in error messages of the form | | ACPI-0293: *** Warning: Buffer created with zero length in AML | | During the 5.1 release process these problems have been temporarily fixed. | | This is due to the Dell laptops having an invalid ACPI table in the BIOS. | The only way to avoid these messages is to tell FreeBSD ACPI to override | the vendor supplied table with a correct one. | | Mark Santcroos developed a patch which worked on his C640 and my Inspiron | 4150, which you can find attached. Here are the steps to use it: [...] I tried that on my Inspiron 4150 with 5.1-RELEASE. The patch failed, but only for trivial reasons like different placment of braces. Note that you have to patch the output of iasl -d, *NOT* the .asl file that acpidump generates. There is a difference although they look alike. Don't ask me what the meaning of all this is, I'm just the messenger :) So I applied it by hand and followed directions, but the warning messages did not go away. I know my efforts did *something* though, as I find this in dmesg output: Preloaded acpi_dsdt /boot/acpi_dsdt.aml at 0xc055c1cc. [...] ACPI: DSDT was overridden. ACPI-0375: *** Info: Table [DSDT] replaced by host OS That's ok, but I think you patched compiled the wrong file. I *know* it works because I also have an Inspiron 4150. Also, I still cannot suspend the machine: acpiconf -s number results in a variety of interesting behaviour, always ending with the machine in a useless state (except acpiconf -s 5, which does what it should - like halt -p). acpiconf -s 4 works, now that I have reinstalled the laptop with a suspend partition as the first primary partition. You need the Dell utility mks2d.exe for this, available somewhere on the Dell website. Actually, acpiconf -s 3 seems to almost work: The screen goes blank, and the machine turns itself off - only to turn back on immediately, but with the screen remaining blank. So I hit Fn-F8 a couple of times, and lo and behold the screen is alive again and the machine is responsive once more. I did this from a console, but when I do Ctrl-Alt-F9 the X server is hosed: Wrong colours, garbage in the top of the screen, and zero response to any keypresses. According to Mark, this actually should work from within X -- something to do with DPMS. I haven't gotten around to testing it after my reinstall though (*cough*Zelda:WW*cough* :) Can you suspend yours? Any more clever tricks? (Hmm, I suppose we should discuss this on -mobile, but since the thread started here...) The ACPI thing got more coverage on -current, but the suspend stuff is probably -mobile topic, yeah :) HTH, --Stijn -- Diane, 2:15 in the afternoon, November 14. Entering town of Twin Peaks. Five miles south of the Canadian border, twelve miles west of the state line. Never seen so many trees in my life. As W.C. Fields would say, I'd rather be here than Philadelphia. -- Special Agent Dale Cooper, Twin Peaks pgp0.pgp Description: PGP signature
Re: PCI bus numbering and orphaned devices
I'm thinking that the loop should be more like: pcifunchigh = 0; f = 0; hdrtype = REG(PCIR_HEADERTYPE, 1); if (hdrtype 0x7f 2) continue; My only complaint about this is that if no device is present in the slot, won't you just get all bits set in whatever you read? If so, the headertype check should be better bounded. -- Justin ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PCI bus numbering and orphaned devices
+*
+* If we don't hardware the bus down, pciconf gets confused.
*/
if (sc-secbus != 0) {
- child = device_add_child(dev, pci, -1);
+ child = device_add_child(dev, pci, sc-secbus);
if (child != NULL)
return (bus_generic_attach(dev));
} else
This one looks good, please commit. The comment above is outdated, so
it might be better to just remove it completely.
At least fix the typo in the comment if you aren't going to remove it.
--
Justin
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PCI bus numbering and orphaned devices
In message: [EMAIL PROTECTED] Justin T. Gibbs [EMAIL PROTECTED] writes: : I'm thinking that the loop should be more like: : : pcifunchigh = 0; : f = 0; : hdrtype = REG(PCIR_HEADERTYPE, 1); : if (hdrtype 0x7f 2) : continue; : : My only complaint about this is that if no device is present in the : slot, won't you just get all bits set in whatever you read? If so, : the headertype check should be better bounded. hdrtype would be 0xff. 0xff 0x7f is 0x7f, which is greater than 2. What would the problem be? The only valid header types are 0, 1, and 2 (at least the only ones that we understand). Technically, if it is a header type we don't know, we're supposed to disable the device in the command register too. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Repeatable panic at boot with ida(4)
With 5.1-RELEASE and all recent SNAP's a Compaq Proliant 1850R I have here will panic during boot. The symptoms are consistent with the report mailed in by Ventsislav Velkov [EMAIL PROTECTED] on March 31st about other Compaq hardware, so it is within the realm of imagination that the machine has been broken for FreeBSD since at least then and that this impacts a variety of hardware. On a verbose boot of the SNAP ISO we see: ... Timecounters tick every 10. msec lo0: bpf attached [0] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 I:0 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 I:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 I:0 [3] f:80 typ:165 s(CHS):0/0/1 e(CHS):1023/254/63 s:0 I:5 GEOM: Configure md0a, start 0 length 4423680 end 4423679 GEOM: Configure md0c, start 0 length 4423680 end 4423679 GEOM: new disk idad0 Fatal trap 12: page fault while in kernel mode ... supervisor read, page not present ... pid is 4 (g_down) ... Stopped at: ida_construct_qcb+0xca: movzbl 0x5c(%eax),%eax db trace ida_construct_qcb... ida_submit_buf... idad_strategy... g_disk_start... g_io_schedule_down... g_down_procbody... fork_exit... fork_trampoline... --- trap 0x1, eip = 0, esp = 0xd6991d7c, ebp = 0 --- It looks like this is coming from around line 396 in /usr/src/sys/dev/ida/ida.c where it bzero()s the hardware qcb... Hopefully someone more familiar with this can give some pointers as to where I can help here. The machine is empty so trial and error consists of burning ISOs/writing .flps and attempting boot with them. Thanks -- William Carrel ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PCI bus numbering and orphaned devices
: I'm thinking that the loop should be more like: : : pcifunchigh = 0; : f = 0; : hdrtype = REG(PCIR_HEADERTYPE, 1); : if (hdrtype 0x7f 2) : continue; : : My only complaint about this is that if no device is present in the : slot, won't you just get all bits set in whatever you read? If so, : the headertype check should be better bounded. hdrtype would be 0xff. 0xff 0x7f is 0x7f, which is greater than 2. Sorry. Read the test backwards. -- Justin ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
smp idle pigs
With recent -current, in the :pigs page of systat(1) I've noticed that
idle time gets displayed on NCPU+1 lines:
NCPU=2:
/0 /10 /20 /30 /40 /50 /60 /70 /80 /90 /100
idle
root idle: cpu0
root idle: cpu1
NCPU=4:
/0 /10 /20 /30 /40 /50 /60 /70 /80 /90 /100
idle XX
root idle: cpu3 XX
root idle: cpu2 XX
root idle: cpu0 XX
root idle: cpu1 XX
No biggy, but maybe someone can have a look at it...
--
:{ [EMAIL PROTECTED]
Andy Farkas
System Administrator
Speednet Communications
http://www.speednet.com.au/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
[-CURRENT tinderbox] failure on sparc64/sparc64
TB --- 2003-06-11 21:32:22 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2003-06-11 21:32:22 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-06-11 21:34:43 - building world TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make -B buildworld Rebuilding the temporary build tree stage 1: legacy release compatibility shims stage 1: bootstrap tools stage 2: cleaning up the object tree stage 2: rebuilding the object tree stage 2: build tools stage 3: cross tools stage 4: populating /home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/include stage 4: building libraries stage 4: make dependencies stage 4: building everything.. TB --- 2003-06-11 22:26:44 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC Kernel build for GENERIC started on Wed Jun 11 22:26:44 GMT 2003 Kernel build for GENERIC completed on Wed Jun 11 22:35:29 GMT 2003 TB --- 2003-06-11 22:35:29 - generating LINT kernel config TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/conf TB --- /usr/bin/make -B LINT TB --- 2003-06-11 22:35:29 - building LINT kernel TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make buildkernel KERNCONF=LINT Kernel build for LINT started on Wed Jun 11 22:35:29 GMT 2003 [...] cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -D_KERNEL -include opt_global.h -fno-common -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/vinum/vinumconfig.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -D_KERNEL -include opt_global.h -fno-common -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/vinum/vinumdaemon.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -D_KERNEL -include opt_global.h -fno-common -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/vinum/vinuminterrupt.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -D_KERNEL -include opt_global.h -fno-common -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/vinum/vinumio.c /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/vinum/vinumio.c: In function `write_volume_label': /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/vinum/vinumio.c:714: `LABELSECTOR' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/vinum/vinumio.c:714: (Each undeclared identifier is reported only once /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/vinum/vinumio.c:714: for each function it appears in.) *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/LINT. *** Error code 1 Stop in
Re: LG 5350 cell phone
On Wed, Jun 11, 2003 at 01:05:00PM -0500, Sean Welch wrote: I have this phone myself. I have two adapters for it -- one is a serial cable the other a true (as in no serial to usb conversion box in the middle) usb cable. The phone works great under FreeBSD on the serial cable (normal Hayes modem type at commands work fine), but no version of FreeBSD has worked with the usb cable so far. I tried 4.8, 5.0-RELEASE, and a few versions of 5.x-CURRENT. The phone is quite usable from my iBook so the cable isn't the issue (the iBook reports it as a Qualcomm -- which is what the sticker says too). I see the message you do, but when I try to use umodem with it the phone continuously reboots itself until detached. I tried something along the lines of what you did to usbdevs a while back but didn't get any improvement. The connection is appreciably faster over the usb port with the true cable when compared to the serial cable; it would be very nice to use it this way on FreeBSD... Sean Maybe the phone doesn't identify itself as a usb modem class, instead relying on a vendor driver. An easy project for someone would be to write a general usb querying tool for displaying the classes, etc that a usb device supports. I've got code kicking around, mostly from Nick Hibma, but I never got around to finishing it off. Joe -- Josef Karthauser ([EMAIL PROTECTED]) http://www.josef-k.net/ FreeBSD (cvs meister, admin and hacker) http://www.uk.FreeBSD.org/ Physics Particle Theory (student) http://www.pact.cpes.sussex.ac.uk/ An eclectic mix of fact and theory. = ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CardBus USB 2.0 Controller (NEC uPD)
On Wed, Jun 11, 2003 at 09:37:35PM +0200, Bernd Walter wrote: On Tue, Jun 10, 2003 at 10:51:10AM -0500, Craig Boston wrote: I recently purchased a generic CompUSA branded CardBus USB 2.0 controller for a challenge to try to get it to work under FreeBSD ;) It appears to use an NEC chip -- one that I've seen reports of the PCI version working -- so at least some of the support for it is already there. I'm willing to take a stab at it and would be grateful if someone can point me in the general direction of where to start. There are known problems with USB2.0 cardbus cards. We have some kind of resource problem - Warner already wrote something about it some time ago. If I pop out the card I get: Neither OHCI nor EHCI controllers have working detach code right now. The detach code could be made to work fairly easily. It's mostly there I believe, but disabled. Nick couldn't convince himself that all the used memory was being returned if the device is suddently unloaded. You could suck it and see. Joe -- Josef Karthauser ([EMAIL PROTECTED]) http://www.josef-k.net/ FreeBSD (cvs meister, admin and hacker) http://www.uk.FreeBSD.org/ Physics Particle Theory (student) http://www.pact.cpes.sussex.ac.uk/ An eclectic mix of fact and theory. = ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ACPI Regression in -CURRENT?
+ Stijn Hoop [EMAIL PROTECTED]: | I tried that on my Inspiron 4150 with 5.1-RELEASE. The patch failed, | but only for trivial reasons like different placment of braces. | | Note that you have to patch the output of iasl -d, *NOT* the .asl file | that acpidump generates. There is a difference although they look alike. Aha. But the diff you included clearly indicated it was a patch for insp4150.asl. When I told patch to patch insp4150.dsl instead, using your patch, it applied cleanly, and moreover the fix now works to the extent that I don't get those error messages anymore. To be precise, I followed your exact instructions with this difference: # patch insp4150.dsl insp4150.patch | Actually, acpiconf -s 3 seems to almost work: [...] | | According to Mark, this actually should work from within X -- | something to do with DPMS. Still doesn't for me. Same result. Maybe I should learn what DPMS stands for. - Harald ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
DRI/XFree86/FreeBSD/OpenGL problem
Hello, I have a problem with DRI on FreeBSD. Specifically, in some OpenGL programs, objects are not drawn at all (in some cases only some of them get drawn) (DRI enabled), but when DRI is disabled all work fine. A simple example of such program is: http://www.opengl.org/developers/code/glut_examples/examples/cube.c The hardware is: AMD Athlon XP 1800+, MSI KT4V (KT400/VT8235), 256MB DDR333 PC2700, Matrox G450 32MB AGP4X The system runs -CURRENT (last updated 2 days ago). Some of the XFree86 ports installed (and their versions): XFree86-4.3.0,1, XFree86-Server-4.3.0_8, XFree86-clients-4.3.0_2, XFree86-libraries-4.3.0_5 Other system information: http://members.hellug.gr/lefcha/dmesg http://members.hellug.gr/lefcha/drm http://members.hellug.gr/lefcha/glxinfo http://members.hellug.gr/lefcha/libgldebug http://members.hellug.gr/lefcha/XF86Config-4 http://members.hellug.gr/lefcha/pciconf Thanks ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CardBus USB 2.0 Controller (NEC uPD)
On Wed, 2003-06-11 at 19:37, Bernd Walter wrote: There are known problems with USB2.0 cardbus cards. We have some kind of resource problem - Warner already wrote something about it some time ago. Ah, thanks. Any hints on where to find it? I tried adding his name to my archive/google searches but keep coming up with many unrelated posts... :-/ About all I've managed to do so far is to verify that it doesn't appear to be an interrupt routing problem. The driver is indeed receiving interrupts. However the status register only says that it's a root hub status change, never to advise that a transfer is complete :-( Polling mode doesn't seem to help as it queries the same register... It also sometimes interrupts with intrs==0 right after a transfer starts, which sounds bogus to me. I'm in single-user mode and positive that nothing else on irq 11 is interrupting. Oh well, for now I'm content to just keep hacking on it and learn more about how the code works :) Craig ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ACPI Regression in -CURRENT?
On Thu, Jun 12, 2003 at 12:46:32AM +0200, Harald Hanche-Olsen wrote: + Stijn Hoop [EMAIL PROTECTED]: | I tried that on my Inspiron 4150 with 5.1-RELEASE. The patch failed, | but only for trivial reasons like different placment of braces. | | Note that you have to patch the output of iasl -d, *NOT* the .asl file | that acpidump generates. There is a difference although they look alike. Aha. But the diff you included clearly indicated it was a patch for insp4150.asl. When I told patch to patch insp4150.dsl instead, using your patch, it applied cleanly, and moreover the fix now works to the extent that I don't get those error messages anymore. To be precise, I followed your exact instructions with this difference: # patch insp4150.dsl insp4150.patch I'm sorry, like I wrote the earlier procedure was typed off of the top of my head, and wasn't verified. I should have done that. | Actually, acpiconf -s 3 seems to almost work: [...] | | According to Mark, this actually should work from within X -- | something to do with DPMS. Still doesn't for me. Same result. Maybe I should learn what DPMS stands for. Something with display power management. But maybe it's something else then. Glad to hear the ACPI messages got sorted out at least :) --Stijn -- I wish there was a knob on the TV to turn up the intelligence. There's a knob called `brightness', but it doesn't work. -- Gallagher pgp0.pgp Description: PGP signature
Re: ACPI Regression in -CURRENT?
On Tue, Jun 10, 2003 at 11:38:18PM -0700, Terry Lambert wrote: Stijn Hoop wrote: This is due to the Dell laptops having an invalid ACPI table in the BIOS. The only way to avoid these messages is to tell FreeBSD ACPI to override the vendor supplied table with a correct one. Alternately, since Microsoft works just peachy with this thing, it's somewhat apparent that the Derefof() and Refof() can be implied by the types of the values being passed, Not that I can read one bit of ASL, but I fail to see how this is apparent. If it is, is it still as apparent to an interpreter? and the ACPI table parsing code should be changed to work like Microsoft's does, at least until FreeBSD displaces the 70% marketshare and can dictate defacto implementation standards, where Intel can't. That would be great except probably nobody knows why this laptop works with Windows without a hitch -- it could very well be that the Dell drivers implement their own battery management and completely ignore the fact that it's broken in their ACPI table. Yeah, I know that it's better to be correct than Microsoft compatible, but it's also better to work with hardware as shipped by vendors. Unless you think you can get Dell to rev their BIOS... That would be great, but I don't have the contacts at Dell. Anybody reading this who does? --Stijn -- This sentence contradicts itself -- no actually it doesn't. -- Hofstadter pgp0.pgp Description: PGP signature
Re: kernel: lnc0: Missed packet -- no reviece buffer QWE
Hi Bruce, -- To email me add QWE to the subject From: Bruce Cran To: Anthony Wyatt CC: [EMAIL PROTECTED] Subject: Re: kernel: lnc0: Missed packet -- no reviece buffer QWE Date: Wed, 11 Jun 2003 15:39:33 +0100 On Wed, Jun 11, 2003 at 09:51:02PM +1000, Anthony Wyatt wrote: Hi Everyone, I'm in the process of hand building a FreeBSD 5.1 CURRENT #2 box. I now have a booting system that I can log onto and use, but my network interface does not work :-( I get lots of: kernel: lnc0: Missed packet -- no recieve buffer and the occasional kernel: lnc0: Device timeout -- resetting I really don't know what to look for, however there are a couple of things that may be related: 1) I have no swap 2) I have not configured anything in particular in /etc, just copied it from my build tree and added a fstab 3) /bin /boot /sbin and /usr are all RO I'm sure its probably under my nose, but I need someone to point out what it is :-) I get this all the time on my FreeBSD 4.8-RELEASE system, which is a P75 with a lnc NIC. The man page does say this driver is one of the more verbose ones, and I think the message about no recieve buffer is just that the system cannot keep up with the incoming data, and so there is no buffer left. Certainly on my system doing NAT across lnc0 and sis0, the system uses 30-40% CPU just to act as a router! I still get 600KB/s through it, which I have heard is fairly reasonable from a 10Mbit ISA network card. -- Bruce Cran _ Hotmail now available on Australian mobile phones. [1]Click here for more. References 1. http://g.msn.com/8HMGENAU/2752??PS= ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel: lnc0: Missed packet -- no reviece buffer QWE
Hi Bruce, Thanks for -- To email me add QWE to the subject From: Bruce Cran To: Anthony Wyatt CC: [EMAIL PROTECTED] Subject: Re: kernel: lnc0: Missed packet -- no reviece buffer QWE Date: Wed, 11 Jun 2003 15:39:33 +0100 On Wed, Jun 11, 2003 at 09:51:02PM +1000, Anthony Wyatt wrote: Hi Everyone, I'm in the process of hand building a FreeBSD 5.1 CURRENT #2 box. I now have a booting system that I can log onto and use, but my network interface does not work :-( I get lots of: kernel: lnc0: Missed packet -- no recieve buffer and the occasional kernel: lnc0: Device timeout -- resetting I really don't know what to look for, however there are a couple of things that may be related: 1) I have no swap 2) I have not configured anything in particular in /etc, just copied it from my build tree and added a fstab 3) /bin /boot /sbin and /usr are all RO I'm sure its probably under my nose, but I need someone to point out what it is :-) I get this all the time on my FreeBSD 4.8-RELEASE system, which is a P75 with a lnc NIC. The man page does say this driver is one of the more verbose ones, and I think the message about no recieve buffer is just that the system cannot keep up with the incoming data, and so there is no buffer left. Certainly on my system doing NAT across lnc0 and sis0, the system uses 30-40% CPU just to act as a router! I still get 600KB/s through it, which I have heard is fairly reasonable from a 10Mbit ISA network card. -- Bruce Cran _ Get mobile Hotmail. [1]Click here References 1. http://g.msn.com/8HMGENAU/2731??PS= ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel: lnc0: Missed packet -- no reviece buffer QWE
Hi Bruce, Thanks for your reply: I get lots of: kernel: lnc0: Missed packet -- no recieve buffer and the occasional kernel: lnc0: Device timeout -- resetting I get this all the time on my FreeBSD 4.8-RELEASE system, which is a P75 with a lnc NIC. The man page does say this driver is one of the more verbose ones, and I think the message about no recieve buffer is just that the system cannot keep up with the incoming data, and so there is no buffer left. Unfortunatly, I can't even ping out this interface at the moment, something seems to be quite broken, and I'm pretty sure its something I've done :-) Once I have the solution, I'll post it back to the list. Thanks again, Anthony _ Hotmail now available on Australian mobile phones. [1]Click here for more. References 1. http://g.msn.com/8HMGENAU/2746??PS= ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ACPI Regression in -CURRENT?
Date: Thu, 12 Jun 2003 01:12:06 +0200 From: Stijn Hoop [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] On Thu, Jun 12, 2003 at 12:46:32AM +0200, Harald Hanche-Olsen wrote: + Stijn Hoop [EMAIL PROTECTED]: | I tried that on my Inspiron 4150 with 5.1-RELEASE. The patch failed, | but only for trivial reasons like different placment of braces. | | Note that you have to patch the output of iasl -d, *NOT* the .asl file | that acpidump generates. There is a difference although they look alike. Aha. But the diff you included clearly indicated it was a patch for insp4150.asl. When I told patch to patch insp4150.dsl instead, using your patch, it applied cleanly, and moreover the fix now works to the extent that I don't get those error messages anymore. To be precise, I followed your exact instructions with this difference: # patch insp4150.dsl insp4150.patch I'm sorry, like I wrote the earlier procedure was typed off of the top of my head, and wasn't verified. I should have done that. | Actually, acpiconf -s 3 seems to almost work: [...] | | According to Mark, this actually should work from within X -- | something to do with DPMS. Still doesn't for me. Same result. Maybe I should learn what DPMS stands for. Something with display power management. But maybe it's something else then. Glad to hear the ACPI messages got sorted out at least :) There are two problems I see with s3 on my ThinkPad (T30): 1. The display back-light stays on. (The bit rot of the display is at least novel. Brings back the 60s and and psychodelia!) 2. The disk spins down INSTANTLY. If the is any un-written data in the write cache, you may have a problem. I have noticed that when I suspend in XP, there is a delay of about 3 seconds before the system actually suspends. It even display a window that says Preparing the system for sleep or something similar. I suspect that at least one function of this is to give the disk caches time to flush. They probably do a DOS equivalent of an sync, as well. I think that this delay needs to be available as I suspect that at least some BIOSes require it to avoid disk corruption. I suspect that XP does something to stop the video and turn off the back-light, but I have no way of guessing what. In V4 days I could use apmd to switch to a vty on suspend, but I have not looked into whether that will work with ACPI. ACPI basically works, but the rough bits keep me on APM. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CardBus USB 2.0 Controller (NEC uPD)
On Wed, Jun 11, 2003 at 11:45:38PM +0100, Josef Karthauser wrote: On Wed, Jun 11, 2003 at 09:37:35PM +0200, Bernd Walter wrote: On Tue, Jun 10, 2003 at 10:51:10AM -0500, Craig Boston wrote: I recently purchased a generic CompUSA branded CardBus USB 2.0 controller for a challenge to try to get it to work under FreeBSD ;) It appears to use an NEC chip -- one that I've seen reports of the PCI version working -- so at least some of the support for it is already there. I'm willing to take a stab at it and would be grateful if someone can point me in the general direction of where to start. There are known problems with USB2.0 cardbus cards. We have some kind of resource problem - Warner already wrote something about it some time ago. If I pop out the card I get: Neither OHCI nor EHCI controllers have working detach code right now. The detach code could be made to work fairly easily. It's mostly there I believe, but disabled. Nick couldn't convince himself that all the used memory was being returned if the device is suddently unloaded. You could suck it and see. I'm not shure if the code would work, but it was also ported into ehci and therefor ehci should be in a similar state. Well loosing memory is better than panic. I have no cardbus - can this be tested with a module? -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CardBus USB 2.0 Controller (NEC uPD)
On Wed, Jun 11, 2003 at 11:08:42PM +, Craig Boston wrote: On Wed, 2003-06-11 at 19:37, Bernd Walter wrote: There are known problems with USB2.0 cardbus cards. We have some kind of resource problem - Warner already wrote something about it some time ago. Ah, thanks. Any hints on where to find it? I tried adding his name to my archive/google searches but keep coming up with many unrelated posts... :-/ Search in current and cvs-all lists for ehci and maybe cardbus. There was a thread shortly after the ehci driver was commited. About all I've managed to do so far is to verify that it doesn't appear to be an interrupt routing problem. The driver is indeed receiving interrupts. However the status register only says that it's a root hub status change, never to advise that a transfer is complete :-( Polling mode doesn't seem to help as it queries the same register... It also sometimes interrupts with intrs==0 right after a transfer starts, which sounds bogus to me. I'm in single-user mode and positive that nothing else on irq 11 is interrupting. Oh well, for now I'm content to just keep hacking on it and learn more about how the code works :) Good luck :) -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: adsl/pppoe no longer connecting on 5.1
I'm having trouble with the latest build of -CURRENT as well. Same problem, slightly different symptoms: Portions of my config file: disable ipv6 deny pap set device PPPoE:xl0 ...produce this in the log (repeatedly): Jun 11 22:00:14 bogushost2 ppp[222]: Warning: Unexpected node type ``socket'' (wanted ``ether'') Jun 11 22:00:14 bogushost2 ppp[222]: Warning: deflink: PPPoE: unknown host Jun 11 22:00:14 bogushost2 ppp[222]: Warning: deflink: PPPoE: unknown host Jun 11 22:00:14 bogushost2 ppp[222]: Warning: deflink: Device (PPPoE:xl0) must egin with a '/', a '!' or contain at least one ':' Jun 11 22:00:14 bogushost2 ppp[222]: Phase: deflink: Enter pause (2) for redialing. Bloody irritating. Andrew Lankford ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
CSTD=c99 breaks package creation
On Tue, Jun 10, 2003 at 04:38:58AM -0700, Kris Kennaway wrote: A couple of ports are creating broken bzip2 archives since I updated the build environments to 5.1-CURRENT: ports-i386%bzip2 -t ja-makejvf-fkr-1.0_1.tbz bzip2: ja-makejvf-fkr-1.0_1.tbz: file ends unexpectedly You can use the `bzip2recover' program to attempt to recover data from undamaged sections of corrupted files. ports-i386%bzip2 -t cclient-2002c1_1,1.tbz bzip2: cclient-2002c1_1,1.tbz: file ends unexpectedly You can use the `bzip2recover' program to attempt to recover data from undamaged sections of corrupted files. They're broken no matter how many times I rebuild them. The bento package cluster machines haven't been updated, so I don't blame a kernel problem, but the build chroot is being populated with a 5.1-CURRENT world instead of 5.1-RELEASE. Can anyone else reproduce this, or has anyone else seen a similar problem? Backing out the recent changes to bsd.sys.mk fixed these problems. I don't know why, but pkg_create was creating packages that were truncated - perhaps tar was closing the pipe early or something. It's possible that there's either a bug in gcc or there is C code in the system that has a different meaning when interpreted to C99 standards. Kris pgp0.pgp Description: PGP signature
Re: adsl/pppoe no longer connecting on 5.1
On Wed, Jun 11, 2003 at 10:34:39PM -0400, Andrew Lankford wrote: I'm having trouble with the latest build of -CURRENT as well. Same problem, slightly different symptoms: Portions of my config file: disable ipv6 deny pap set device PPPoE:xl0 ...produce this in the log (repeatedly): Can you try backing out bsd.sys.mk to r1.26 and rebuild your world and kernel? Later versions of this file are causing strange problems with package builds. Kris pgp0.pgp Description: PGP signature
Re: adsl/pppoe no longer connecting on 5.1
On Thu, 12 Jun 2003 12:04, Andrew Lankford wrote: I'm having trouble with the latest build of -CURRENT as well. Same problem, slightly different symptoms: Portions of my config file: disable ipv6 deny pap set device PPPoE:xl0 ...produce this in the log (repeatedly): Jun 11 22:00:14 bogushost2 ppp[222]: Warning: Unexpected node type ``socket'' (wanted ``ether'') Jun 11 22:00:14 bogushost2 ppp[222]: Warning: deflink: PPPoE: unknown host Jun 11 22:00:14 bogushost2 ppp[222]: Warning: deflink: PPPoE: unknown host Jun 11 22:00:14 bogushost2 ppp[222]: Warning: deflink: Device (PPPoE:xl0) must egin with a '/', a '!' or contain at least one ':' Jun 11 22:00:14 bogushost2 ppp[222]: Phase: deflink: Enter pause (2) for redialing. Bloody irritating. Are all of the lines except labels prefixed with a space? eg. default: set openmode active foo: set device PPPoE:xl0 set authname xyz set authkey abc If you don't have the spaces I thnk the parser chokes on the : for PPPoE.. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
CURRENT console setttings borked
Info about my buildworld: FreeBSD bogushost2 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Wed Jun 11 21:33:34 EDT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/ARL5KERNEL i386 In addition to my pppoe/adsl connection no longer working, I find that I cannot use control-c to kill running programs when I'm logged in directly to the console (without invoking stty intr ^c first) yerprompt$ stty #(syscons console, TERM=cons25) speed 115200 baud; lflags: echoe echoke echoctl pendin oflags: -oxtabs cflags: cs8 -parenb discard dsusp eof erase intrkilllnext quitreprint undef undef undef undef undef undef undef undef undef start stopsuspwerase undef undef undef undef ...although an xterm seems to behave itself (almost) yerprompt$ stty #(TERM=xterm) speed 38400 baud; lflags: echoe echok echoke echoctl pendin iflags: -ixany ignpar oflags: -oxtabs cflags: cs8 -parenb -hupcl erase2 status undef ^E Hope this helps unbreak whatever's broken Andrew Lankford ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
sh job control
I've installed a current built last night and job control no longer works in /bin/sh or /usr/local/bin/zsh, but it does with csh. ctr-c and ctrl-z are just ignored with both the sh style shells. -- Tis a wise thing to know what is wanted, wiser still to know when it has been achieved and wisest of all to know when it is unachievable for then striving is folly. [Magician] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CURRENT console setttings borked
On Wed, Jun 11, 2003 at 11:21:16PM -0400, Andrew Lankford wrote: Info about my buildworld: FreeBSD bogushost2 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Wed Jun 11 21:33:34 EDT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/ARL5KERNEL i386 In addition to my pppoe/adsl connection no longer working, I find that I cannot use control-c to kill running programs when I'm logged in directly to the console (without invoking stty intr ^c first) yerprompt$ stty #(syscons console, TERM=cons25) speed 115200 baud; lflags: echoe echoke echoctl pendin oflags: -oxtabs cflags: cs8 -parenb discard dsusp eof erase intrkilllnext quitreprint undef undef undef undef undef undef undef undef undef start stopsuspwerase undef undef undef undef Ahh, that's what I'm seeing too, but not with csh, just bourne style shells. -- Tis a wise thing to know what is wanted, wiser still to know when it has been achieved and wisest of all to know when it is unachievable for then striving is folly. [Magician] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel: lnc0: Missed packet -- no reviece buffer QWE
On Wed, Jun 11, 2003 at 03:39:33PM +0100, Bruce Cran wrote: I get this all the time on my FreeBSD 4.8-RELEASE system, which is a P75 with a lnc NIC. The man page does say this driver is one of the more verbose ones, and I think the message about no recieve buffer is just that the system cannot keep up with the incoming data, and so there is no buffer left. Certainly on my system doing NAT across lnc0 and sis0, the system uses 30-40% CPU just to act as a router! I still get 600KB/s through it, which I have heard is fairly reasonable from a 10Mbit ISA network card. That is what the error message means. However, the driver was able to handle 900k-1M load on a 486 when I wrote without maxing out the cpu so there's something wrong somewhere. It might be the sis driver though, I don't know much about that but I've not heard good things about them. The lance does most of it's work on the chip so all that the CPU does is copy the buffers into an mbuf, which shouldn't put much load on the cpu. Is it possible for you to do some testing on that box by disabling each interface in turn and doing some load testing on each individually? -- Tis a wise thing to know what is wanted, wiser still to know when it has been achieved and wisest of all to know when it is unachievable for then striving is folly. [Magician] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
*IT WORKS* Re: CardBus USB 2.0 Controller (NEC uPD)
Believe it or not, after futzing with the debugger for hours, reading the OHCI spec, and trying to figure out why writing to the control registers works exactly as it should but the card seems to ignore the ED list, I decided to try something completely crazy and put the line pci_enable_busmaster(self); near the top of ohci_attach() in ohci_pci.c ...and it worked! I believe my first words upon seeing ums0: blah blah were You have GOT to be kidding me. My logic was that since the driver allocates a DMA buffer in main memory that the card is supposed to read/write to, maybe cardbus cards have additional restrictions on what parts of system RAM they can touch and might have to use bus mastering to do it. I don't know if that's a valid assumption or not, but in any case the driver functions perfectly with every USB 1.1 and 2.0 (put the same line in ehci_pci.c) device I've tried so far. My USB 2.0 hard drive enclosure is getting around 8MB/s for reads and 7MB/s for writes. I don't know if that's good or not, or even what the physical limitations of the drive I have in there are, but it's still much improved from the ~ 800KB/s I was getting using in compatibility mode on the built-in USB port. I'm attaching a (trivial) patch for the lazy :) Be advised, this is far from a general solution as it probably breaks some (many?) PCI-based controllers that don't support bus mastering. Craig ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CardBus USB 2.0 Controller (NEC uPD)
On Wednesday 11 June 2003 07:21 pm, Bernd Walter wrote: On Wed, Jun 11, 2003 at 11:45:38PM +0100, Josef Karthauser wrote: The detach code could be made to work fairly easily. It's mostly there I believe, but disabled. Nick couldn't convince himself that all the used memory was being returned if the device is suddently unloaded. You could suck it and see. I'm not shure if the code would work, but it was also ported into ehci and therefor ehci should be in a similar state. Well loosing memory is better than panic. I have no cardbus - can this be tested with a module? I'd be more than happy to give it a shot on my now-working cardbus card and see what happens. It is as simple as adding DEVMETHOD(device_detach, ohci_pci_detach) to the device_method_t ? Craig ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CSTD=c99 breaks package creation
On Wed, Jun 11, 2003 at 07:37:01PM -0700, Kris Kennaway wrote:
It's possible that there's either a bug in gcc or there is C code in
the system that has a different meaning when interpreted to C99
standards.
I think I may have found the problem, and I think it's in GNU tar.
GNU tar does this:
#ifndef __attribute__
/* This feature is available in gcc versions 2.5 and later. */
# if __GNUC__ 2 || (__GNUC__ == 2 __GNUC_MINOR__ 5) || __STRICT_ANSI__
# define __attribute__(Spec) /* empty */
# endif
#endif
machine/_types.h does this:
typedef int __attribute__((__mode__(__DI__))) __int64_t;
typedef unsigned int __attribute__((__mode__(__DI__))) __uint64_t;
If __attribute__ is empty, __int64_t becomes a synonym for int. Bad.
Attached is a test program. Compile it w/o a -std option and see that the
output, which is sizeof(int64_t), is 8 as expected. Compile with -std=c99 and
see that sizeof(int64_t) is 4.
Tim
#ifndef __attribute__
/* This feature is available in gcc versions 2.5 and later. */
# if __GNUC__ 2 || (__GNUC__ == 2 __GNUC_MINOR__ 5) || __STRICT_ANSI__
# define __attribute__(Spec) /* empty */
# endif
#endif
#include sys/types.h
#include stdio.h
#include stdint.h
#include stdlib.h
int
main(int argc, char *argv[])
{
(void)__bswap64((uint64_t)3);
printf(%d\n, (int)sizeof(uint64_t));
exit(0);
}
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: adsl/pppoe no longer connecting on 5.1
Can you try backing out bsd.sys.mk to r1.26 and rebuild your world and kernel? Later versions of this file are causing strange problems with package builds. I was a little lazy and just backed out bsd.sys.mk to 1.26 as you suggested, rebuilt /usr/lib/ , /usr/include/, and ppp. My kernel is the same as last time. As a result, ppp's now up and running again. Thanks for the help. Andrew Lankford ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: adsl/pppoe no longer connecting on 5.1
On Wed, Jun 11, 2003 at 10:48:32PM -0600, Andrew Lankford wrote: Can you try backing out bsd.sys.mk to r1.26 and rebuild your world and kernel? Later versions of this file are causing strange problems with package builds. I was a little lazy and just backed out bsd.sys.mk to 1.26 as you suggested, rebuilt /usr/lib/ , /usr/include/, and ppp. My kernel is the same as last time. As a result, ppp's now up and running again. Thanks, that's actually more useful because it isolates the problem. It's probably something in ppp that is misbehaving with CSTD=c99. Kris pgp0.pgp Description: PGP signature
Re: Correct PCI suspend and resume operations
In message: [EMAIL PROTECTED] Orion Hodson [EMAIL PROTECTED] writes: : It looks like the pci configuration space state has been lost during : the suspend and resume. This may be because the bus has removed power : from the devices attached to it on suspend. During a suspend, devices are typically set into D3 state. Transition from D3 - D0 resets the most of the config space. : I've been through a cross section of drivers this morning and some : explicitly save and restore the PCI configuration state space and : others don't. The former seems like the safest path in most cases. : AFAICT, we don't common code for handling this and maybe there should : be some rather than have each driver replicate this behaviour. This should be saved in the pci bus layer. I have some very imperfect patches in my p4 tree that I'm working on. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: adsl/pppoe no longer connecting on 5.1
Thanks, that's actually more useful because it isolates the problem. It's probably something in ppp that is misbehaving with CSTD=c99. True. A simple rebuild of ppp (without libc, etc.) didn't change anything. Andrew Lankford ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Correct PCI suspend and resume operations
In message: [EMAIL PROTECTED] Mark Santcroos [EMAIL PROTECTED] writes: : On Tue, Jun 10, 2003 at 09:15:05PM +0200, Mark Santcroos wrote: : AFAICT, we don't common code for handling this and maybe there should : be some rather than have each driver replicate this behaviour. : : In general, that would of course be better. However, I don't know if the : PCI layer (in this case) always knows enough. : On the other side, if the device itself has to do some special things, the : PCI layer could at least do the generic stuff. : : To be more precise, the suspend function should know the powerstate it is : transitioning to. If it keeps context (D0-D2) it doesn't need to do much : special, if it will loose context (D3) it should save the state at : suspend, and restore the state at resume. Sadly, in the current scheme, the device driver has no way of knowing what the new power state is going to be. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CardBus USB 2.0 Controller (NEC uPD)
In message: [EMAIL PROTECTED] Bernd Walter [EMAIL PROTECTED] writes: : On Tue, Jun 10, 2003 at 10:51:10AM -0500, Craig Boston wrote: : I recently purchased a generic CompUSA branded CardBus USB 2.0 : controller for a challenge to try to get it to work under FreeBSD ;) It : appears to use an NEC chip -- one that I've seen reports of the PCI : version working -- so at least some of the support for it is already : there. I'm willing to take a stab at it and would be grateful if : someone can point me in the general direction of where to start. : : There are known problems with USB2.0 cardbus cards. : We have some kind of resource problem - Warner already wrote something : about it some time ago. I have one of these cards, but haven't had the time to look into why. : If I pop out the card I get: : : Neither OHCI nor EHCI controllers have working detach code right now. Nor UHCI, from what I can tell. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: *IT WORKS* Re: CardBus USB 2.0 Controller (NEC uPD)
Cut-and-paste of the patch since the attachment disappeared... Probably won't apply cleanly because of tabs. --- ohci_pci.c.orig 2003-06-11 22:32:42.0 -0500 +++ ohci_pci.c 2003-06-11 22:01:43.0 -0500 @@ -173,6 +173,8 @@ /* XXX where does it say so in the spec? */ sc-sc_bus.usbrev = USBREV_1_0; + pci_enable_busmaster(self); + rid = PCI_CBMEM; sc-io_res = bus_alloc_resource(self, SYS_RES_MEMORY, rid, 0, ~0, 1, RF_ACTIVE); --- ehci_pci.c.orig 2003-06-11 22:32:36.0 -0500 +++ ehci_pci.c 2003-06-11 22:33:08.0 -0500 @@ -158,6 +158,8 @@ break; } + pci_enable_busmaster(self); + rid = PCI_CBMEM; sc-io_res = bus_alloc_resource(self, SYS_RES_MEMORY, rid, 0, ~0, 1, RF_ACTIVE); ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: adsl/pppoe no longer connecting on 5.1
On Wed, Jun 11, 2003 at 09:50:22PM -0700, Kris Kennaway wrote: On Wed, Jun 11, 2003 at 10:48:32PM -0600, Andrew Lankford wrote: Can you try backing out bsd.sys.mk to r1.26 and rebuild your world and kernel? Later versions of this file are causing strange problems with package builds. I was a little lazy and just backed out bsd.sys.mk to 1.26 as you suggested, rebuilt /usr/lib/ , /usr/include/, and ppp. My kernel is the same as last time. As a result, ppp's now up and running again. Thanks, that's actually more useful because it isolates the problem. It's probably something in ppp that is misbehaving with CSTD=c99. alloca(3) function is misbehaving in ppp (namely ether.c). Is this a compiler bug? Cheers, Wiktor Niesiobedzki ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: adsl/pppoe no longer connecting on 5.1
On Thu, Jun 12, 2003 at 07:18:12AM +0200, Wiktor Niesiobedzki wrote: On Wed, Jun 11, 2003 at 09:50:22PM -0700, Kris Kennaway wrote: On Wed, Jun 11, 2003 at 10:48:32PM -0600, Andrew Lankford wrote: Can you try backing out bsd.sys.mk to r1.26 and rebuild your world and kernel? Later versions of this file are causing strange problems with package builds. I was a little lazy and just backed out bsd.sys.mk to 1.26 as you suggested, rebuilt /usr/lib/ , /usr/include/, and ppp. My kernel is the same as last time. As a result, ppp's now up and running again. Thanks, that's actually more useful because it isolates the problem. It's probably something in ppp that is misbehaving with CSTD=c99. alloca(3) function is misbehaving in ppp (namely ether.c). Is this a compiler bug? alloca() is not being inlined when -std is specified. It is possible there's a bug in the libc implementation. I'm also suspicious that some of the ppp data structures have changed size or alignment which could be confusing netgraph. Kris pgp0.pgp Description: PGP signature
Re: adsl/pppoe no longer connecting on 5.1
On Thu, Jun 12, 2003 at 07:18:12AM +0200, Wiktor Niesiobedzki wrote: On Wed, Jun 11, 2003 at 09:50:22PM -0700, Kris Kennaway wrote: On Wed, Jun 11, 2003 at 10:48:32PM -0600, Andrew Lankford wrote: Can you try backing out bsd.sys.mk to r1.26 and rebuild your world and kernel? Later versions of this file are causing strange problems with package builds. I was a little lazy and just backed out bsd.sys.mk to 1.26 as you suggested, rebuilt /usr/lib/ , /usr/include/, and ppp. My kernel is the same as last time. As a result, ppp's now up and running again. Thanks, that's actually more useful because it isolates the problem. It's probably something in ppp that is misbehaving with CSTD=c99. alloca(3) function is misbehaving in ppp (namely ether.c). Is this a compiler bug? Misbehaving in what way? CSTD=c99 causes gcc to use alloca() from libc instead of its builtin version. Perhaps alloca() in libc is broken -- any bugs in it would have been covered up by gcc until now. Tim ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FTP and command-line multiple downloads
On 06-Jun-2003 Yar Tikhiy wrote: | | Luke Mewburn may be convinced to do that | in his ftp client. Technically, the task is as easy as removing a | single logical subexpression from an if statement. | When I proposed the patch to Luke back in February he was hesistant to implement it. He mentioned that he had already gotten into trouble by not implementing RFC 1738 exactly -- which doesn't include globbing URL's. Mike -- Mike Heffner [EMAIL PROTECTED] [EMAIL PROTECTED] pgp0.pgp Description: PGP signature
