Re: cvs commit: src/sys/cam cam_ccb.h src/sys/cam/scsi scsi_cd.c scsi_da.c src/sys/dev/ata atapi-cam.c src/sys/dev/usb umass.c src/sys/dev/firewire sbp.c
On Sun, 27 Jul 2003, Nate Lawson wrote: Modified files: sys/cam cam_ccb.h sys/cam/scsi scsi_da.c scsi_cd.c sys/dev/ata atapi-cam.c sys/dev/usb umass.c sys/dev/firewire sbp.c Log: Add a PATH_INQ flag, PIM_NO_6_BYTE, which indicates the SIM never wishes to receive 6 byte commands. Add a check for this flag to da(4) and cd(4) so that they honor it. This is a quick workaround for many devices (especially USB) that require da(4) quirks to operate. The more complete approach is to finish the new transport code which will be aware of the SCSI version a transport implements. MFC after: 1 day Revision ChangesPath 1.26 +2 -1 src/sys/cam/cam_ccb.h 1.80 +8 -0 src/sys/cam/scsi/scsi_cd.c 1.147 +8 -0 src/sys/cam/scsi/scsi_da.c 1.18 +1 -1 src/sys/dev/ata/atapi-cam.c 1.58 +1 -1 src/sys/dev/firewire/sbp.c 1.88 +1 -1 src/sys/dev/usb/umass.c This is the first step to removing many of the da(4) quirks that have accumulated for USB devices. This code should remove the message: READ(6)/WRITE(6) not supported, increasing minimum_cmd_size to 10. It should also fix USB devices which fail when receiving 6 byte commands but do not yet have a quirk. After this code is in both stable and current, current USB quirks will be deprecated but can be re-enabled in a pinch with a kernel option. Unfortunately, I only have contact information for the more recent quirks that were committed and so the only way to find devices that have other problems (i.e. NO_SYNC_CACHE) is to disable the quirks and re-enable them for devices that still fail. I'm doing this as early as possible before 5.2 to get things sorted out and if your device fails at that point, it can be returned to ordinary behavior with a kernel option until I remove it from the deprecated section. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[current tinderbox] failure on amd64/amd64
TB --- 2003-07-28 05:22:26 - starting CURRENT tinderbox run for amd64/amd64 TB --- 2003-07-28 05:22:26 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/amd64/amd64 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-07-28 05:24:14 - building world TB --- cd /home/des/tinderbox/CURRENT/amd64/amd64/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/amd64/amd64/obj/amd64/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/i386/usr/include stage 4: building libraries stage 4: make dependencies stage 4: building everything.. TB --- 2003-07-28 06:24:10 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/amd64/amd64/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC Kernel build for GENERIC started on Mon Jul 28 06:24:10 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/amd64/amd64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/cam/scsi/scsi_ch.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/amd64/amd64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/cam/scsi/scsi_da.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/amd64/amd64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/cam/scsi/scsi_pass.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/amd64/amd64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/cam/scsi/scsi_sa.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes
Re: device driver memory leak in 5.1-20030726?
Lukas Ertl wrote this message on Sun, Jul 27, 2003 at 16:43 +0200: I have different core dumps and backtraces available, but they don't seem to be of much use in this case. I really suspect the USB stuff to be leaking. Ok, if you truely think this is the case, recompile w/ USB_DEBUG, and after everything is setup, and you see devbuf steadily increasing, set the sysctl hw.usb.debug to 7. Take about 10k or so of that, and send it to me. That should let me know if we are leaking. Thanks. -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Belkin F5D5020 PCMCIA Card/Notebook Network Card
Does support for the Belkin F5D5020 PCMCIA Card/Notebook Network Card exist in FreeBSD 5.0-RELEASE? According to Belkin, it does, but I have been unable to find any support for this card. Any suggestions on the right place to look are more than welcome. Here's the mfg's site: http://catalog.belkin.com/IWCatProductPage.process?Merchant_Id=1Product_Id= 104984# and the page that shows FreeBSD support: http://www.belkin.com/network/F5D5020.html Thanks! Regards, Nick H. [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: device driver memory leak in 5.1-20030726?
Ok, you asked for it.. Jul 28 10:13:02 maddog kernel: usbd_alloc_xfer() = 0xc1c92900 Jul 28 10:13:02 maddog kernel: usbd_bulk_transfer: start transfer 53 bytes Jul 28 10:13:02 maddog kernel: usbd_transfer: xfer=0xc1c92900, flags=0, pipe=0xc1bb5480, running=0 Jul 28 10:13:02 maddog kernel: usbd_dump_queue: pipe=0xc1bb5480 Jul 28 10:13:02 maddog kernel: usb_allocmem: use frag=0xc18b1ec0 size=53 Jul 28 10:13:02 maddog kernel: usb_insert_transfer: pipe=0xc1bb5480 running=0 timeout=0 Jul 28 10:13:02 maddog kernel: usb_transfer_complete: pipe=0xc1bb5480 xfer=0xc1c92900 status=0 actlen=53 Jul 28 10:13:02 maddog kernel: usb_freemem: frag=0xc18b1ec0 Jul 28 10:13:02 maddog kernel: usb_transfer_complete: repeat=0 new head=0 Jul 28 10:13:02 maddog kernel: usbd_start_next: pipe=0xc1bb5480, xfer=0 Jul 28 10:13:02 maddog kernel: usbd_bulk_transfer: transferred 53 Jul 28 10:13:02 maddog kernel: usbd_free_xfer: 0xc1c92900 Jul 28 10:13:02 maddog kernel: usb_transfer_complete: pipe=0xc1bb5500 xfer=0xc19acc00 status=0 actlen=53 Jul 28 10:13:02 maddog kernel: usb_freemem: large free Jul 28 10:13:02 maddog kernel: usb_block_freemem: size=4096 Jul 28 10:13:02 maddog kernel: usb_transfer_complete: repeat=0 new head=0 Jul 28 10:13:02 maddog kernel: usbd_start_next: pipe=0xc1bb5500, xfer=0 Jul 28 10:13:02 maddog kernel: usbd_bulk_transfer: transferred 53 Jul 28 10:13:02 maddog kernel: usbd_free_xfer: 0xc19acc00 Jul 28 10:13:02 maddog kernel: usbd_alloc_xfer() = 0xc19acc00 Jul 28 10:13:02 maddog kernel: usbd_bulk_transfer: start transfer 1024 bytes Jul 28 10:13:02 maddog kernel: usbd_transfer: xfer=0xc19acc00, flags=4, pipe=0xc1bb5500, running=0 Jul 28 10:13:02 maddog kernel: usbd_dump_queue: pipe=0xc1bb5500 Jul 28 10:13:02 maddog kernel: usb_allocmem: large alloc 1024 Jul 28 10:13:02 maddog kernel: usb_block_allocmem: size=4096 align=1 Jul 28 10:13:02 maddog kernel: usb_block_allocmem: no free Jul 28 10:13:02 maddog kernel: usb_insert_transfer: pipe=0xc1bb5500 running=0 timeout=0 Jul 28 10:13:02 maddog kernel: usbd_alloc_xfer() = 0xc1c92900 Jul 28 10:13:02 maddog kernel: usbd_bulk_transfer: start transfer 106 bytes Jul 28 10:13:02 maddog kernel: usbd_transfer: xfer=0xc1c92900, flags=0, pipe=0xc1bb5480, running=0 Jul 28 10:13:02 maddog kernel: usbd_dump_queue: pipe=0xc1bb5480 Jul 28 10:13:02 maddog kernel: usb_allocmem: large alloc 106 Jul 28 10:13:02 maddog kernel: usb_block_allocmem: size=4096 align=1 Jul 28 10:13:02 maddog kernel: usb_block_allocmem: no free Jul 28 10:13:02 maddog kernel: usb_insert_transfer: pipe=0xc1bb5480 running=0 timeout=0 Jul 28 10:13:02 maddog kernel: usb_transfer_complete: pipe=0xc1bb5480 xfer=0xc1c92900 status=0 actlen=106 Jul 28 10:13:02 maddog kernel: usb_freemem: large free Jul 28 10:13:02 maddog kernel: usb_block_freemem: size=4096 Jul 28 10:13:02 maddog kernel: usb_transfer_complete: repeat=0 new head=0 Jul 28 10:13:02 maddog kernel: usbd_start_next: pipe=0xc1bb5480, xfer=0 Jul 28 10:13:02 maddog kernel: usbd_bulk_transfer: transferred 106 Jul 28 10:13:02 maddog kernel: usbd_free_xfer: 0xc1c92900 Jul 28 10:13:02 maddog kernel: usb_transfer_complete: pipe=0xc1bb5500 xfer=0xc19acc00 status=0 actlen=106 Jul 28 10:13:02 maddog kernel: usb_freemem: large free Jul 28 10:13:02 maddog kernel: usb_block_freemem: size=4096 Jul 28 10:13:02 maddog kernel: usb_transfer_complete: repeat=0 new head=0 Jul 28 10:13:02 maddog kernel: usbd_start_next: pipe=0xc1bb5500, xfer=0 Jul 28 10:13:02 maddog kernel: usbd_bulk_transfer: transferred 106 Jul 28 10:13:02 maddog kernel: usbd_free_xfer: 0xc19acc00 Jul 28 10:13:02 maddog kernel: usbd_alloc_xfer() = 0xc19acc00 Jul 28 10:13:02 maddog kernel: usbd_bulk_transfer: start transfer 1024 bytes Jul 28 10:13:02 maddog kernel: usbd_transfer: xfer=0xc19acc00, flags=4, pipe=0xc1bb5500, running=0 Jul 28 10:13:02 maddog kernel: usbd_dump_queue: pipe=0xc1bb5500 Jul 28 10:13:02 maddog kernel: usb_allocmem: large alloc 1024 Jul 28 10:13:02 maddog kernel: usb_block_allocmem: size=4096 align=1 Jul 28 10:13:02 maddog kernel: usb_block_allocmem: no free Jul 28 10:13:02 maddog kernel: usb_insert_transfer: pipe=0xc1bb5500 running=0 timeout=0 Jul 28 10:13:07 maddog kernel: usbd_alloc_xfer() = 0xc1c92900 Jul 28 10:13:07 maddog kernel: usbd_bulk_transfer: start transfer 53 bytes Jul 28 10:13:07 maddog kernel: usbd_transfer: xfer=0xc1c92900, flags=0, pipe=0xc1bb5480, running=0 Jul 28 10:13:07 maddog kernel: usbd_dump_queue: pipe=0xc1bb5480 Jul 28 10:13:07 maddog kernel: usb_allocmem: use frag=0xc18b1ec0 size=53 Jul 28 10:13:07 maddog kernel: usb_insert_transfer: pipe=0xc1bb5480 running=0 timeout=0 Jul 28 10:13:07 maddog kernel: usb_transfer_complete: pipe=0xc1bb5480 xfer=0xc1c92900 status=0 actlen=53 Jul 28 10:13:07 maddog kernel: usb_freemem: frag=0xc18b1ec0 Jul 28 10:13:07 maddog kernel: usb_transfer_complete: repeat=0 new head=0 Jul 28 10:13:07 maddog kernel: usbd_start_next: pipe=0xc1bb5480, xfer=0 Jul 28 10:13:07 maddog kernel: usbd_bulk_transfer: transferred 53 Jul 28 10:13:07
Re: SSH from host to jail
28.07.2003, 00:25, Pat Lashley wrote: I'm trying to set up some jails in a 5.1R system. I've pretty much copied a setup that was working fine in 4.8; but on 5.1 I can't seem to SSH from the host system into one of its jails. It acts like the packets just aren't getting through. I would really appreciate it if somebody would send me rc.conf fragments that are known to work for setting up a jail's IP alias and routing on 5.1. Errr... Random shot: Have you told ssh on host not to listen on all addresses it'll find? I use 'ListenAddress' directive in /etc/ssh/sshd_config ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Belkin F5D5020 PCMCIA Card/Notebook Network Card
At 2:38 AM -0500 2003/07/28, Nick H. - Network Operations wrote: Does support for the Belkin F5D5020 PCMCIA Card/Notebook Network Card exist in FreeBSD 5.0-RELEASE? According to Belkin, it does, but I have been unable to find any support for this card. Any suggestions on the right place to look are more than welcome. Back in October of last year, I cooked up a pccard.conf entry for it that seemed to mostly work: # Belkin F5D5020 NE2000-compatible card (FCC ID: LXLC1LANTB) card Belkin F5D5020-PCMCIA-Network-Card config auto ed ? logstr Belkin F5D5020 10/100 Base-TX Ethernet 16-bit PCMCIA card (NE2000-compatible) insert /etc/pccard_ether $device start remove /etc/pccard_ether $device stop I submitted this to Warner Losh, but IIRC, I got an indication back that this wasn't right. However, I don't recall that I ever got any correct pccard.conf setting for this device, and while I could get FreeBSD to see the card and use this entry to mostly recognize it, I could not actually get any positive network results this way. Any additional information you can find would be appreciated. Right now, I'm using a Linksys (EtherFast 10/100 Integrated PC Card (PCM100) on the machine where I was trying to use the Belkin, but it sticks out from the machine and blocks the second PC Card slot, so I'd prefer to use the Belkin (which is flush with the edge and comes with a dongle), if possible. If I could get them both working, or get one of them working with one of my various 802.11b WiFi cards, then I would have two NICs and could do some much more interesting things with this machine. Unfortunately, everything seems to want IRQ3, so even if I could get the individual cards working by themselves, I don't know if I could ever get them working together. I did find an interesting entry at http://www.freebsdforums.org/forums/showthread.php?threadid=8315, at the bottom (dated April 2002) that shows the pccard.conf entry of: # Belkin F5D5020 card Belkin F5D5020-PCMCIA-Network-Card config auto ed ? 0x10 insert /etc/pccard_ether $device start remove /etc/pccard_ether $device stop Which the author claims (claimed) works (worked) for him. You can see my posts from October of last year at http://docs.freebsd.org/cgi/getmsg.cgi?fetch=753513+0+archive/2002/freebsd-questions/20021013.freebsd-questions, http://docs.freebsd.org/cgi/getmsg.cgi?fetch=2755078+0+archive/2002/freebsd-questions/20021013.freebsd-questions, and http://docs.freebsd.org/cgi/getmsg.cgi?fetch=750581+0+archive/2002/freebsd-questions/20021013.freebsd-questions. And then there's the post at http://lists.freebsd.org/pipermail/freebsd-questions/2003-April/001987.html from April, which also mentions this card. But still, no answers to this question. Unfortunately, just Googling for Belkin F5D5020 FreeBSD doesn't do much good, as it turns up many resellers of this card which claims that it works with FreeBSD, or articles that happen to mention both FreeBSD and this card on the same page (such as http://www.23degrees.net/mt/archives/000135.html), but which don't actually provide any solutions. -- Brad Knowles, [EMAIL PROTECTED] They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++): a C++(+++)$ UMBSHI$ P+++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++ h--- r---(+++)* z(+++) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: device driver memory leak in 5.1-20030726?
On Sun, 27 Jul 2003, John-Mark Gurney wrote: Lukas Ertl wrote this message on Sun, Jul 27, 2003 at 16:43 +0200: I have different core dumps and backtraces available, but they don't seem to be of much use in this case. I really suspect the USB stuff to be leaking. Ok, if you truely think this is the case, recompile w/ USB_DEBUG, and after everything is setup, and you see devbuf steadily increasing, set the sysctl hw.usb.debug to 7. Take about 10k or so of that, and send it to me. That should let me know if we are leaking. You can find lots of logging at http://mailbox.univie.ac.at/~le/usb.debug.log. regards, le -- Lukas Ertl eMail: [EMAIL PROTECTED] UNIX Systemadministrator Tel.: (+43 1) 4277-14073 Vienna University Computer Center Fax.: (+43 1) 4277-9140 University of Vienna http://mailbox.univie.ac.at/~le/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[RESOLVED] Belkin F5D5020 PCMCIA Card/Notebook Network Card
I auctually got it working under FreeBSD 4.8. Eventually (read: after next weekend) I plan on attempting to get it working under 5.X. Unfortunately I need the laptop for an event that is happening this week. Anyways, it's working and here's the relevant file settings used: ## FOR FREEBSD 4.X ## /etc/rc.conf: pccard_enable=YES pccard_mem=DEFAULT pccardd_flags= -i 10 the -i 10 sets the IRQ on the device to 10 (dont ask how I found it... Ive already closed Opera ;D) and it's using the following in the /etc/defaults/pccard.conf: # Belkin F5D5020 card Belkin F5D5020-PCMCIA-Network-Card config auto ed ? 0x10 insert /etc/pccard_ether $device start remove /etc/pccard_ether $device stop The thing is up and running fine. dmesg output: pcic0: Polling mode pccard0: PC Card 16-bit bus (classic) on pcic0 pccard1: PC Card 16-bit bus (classic) on pcic0 ... pccard: card inserted, slot 0 ... Setup PC-CARD: memory beep pccardd ... Jul 28 03:55:30 pccardd[47]: Card Belkin(F5D5020-PCMCIA-Network-Card) [V1] [0] matched Belkin (F5D5020-PCMCIA-Network-Card) [(null)] [(null)] ... Jul 28 03:55:35 pccardd[47]: ed1: Belkin (F5D5020-PCMCIA-Network-Card) inserted. ... Jul 28 03:56:45 pccardd[47]: pccardd started The device is running just fine. Hopefully, this is of some help to you, as if I understand you correctly, you're having issues with the IRQ setting. Try the pccardd_flags= -i ## where ## is the IRQ you want it to use. Anyways, all is working well now. Regards, Nick H. [EMAIL PROTECTED] - Original Message - From: Brad Knowles [EMAIL PROTECTED] To: Nick H. - Network Operations [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; M. Warner Losh [EMAIL PROTECTED] Sent: Monday, July 28, 2003 3:23 AM Subject: Re: Belkin F5D5020 PCMCIA Card/Notebook Network Card : At 2:38 AM -0500 2003/07/28, Nick H. - Network Operations wrote: : : Does support for the Belkin F5D5020 PCMCIA Card/Notebook Network Card exist : in FreeBSD 5.0-RELEASE? According to Belkin, it does, but I have been : unable to find any support for this card. Any suggestions on the right : place to look are more than welcome. : : Back in October of last year, I cooked up a pccard.conf entry for : it that seemed to mostly work: : : # Belkin F5D5020 NE2000-compatible card (FCC ID: LXLC1LANTB) : card Belkin F5D5020-PCMCIA-Network-Card : config auto ed ? : logstr Belkin F5D5020 10/100 Base-TX Ethernet 16-bit PCMCIA : card (NE2000-compatible) : insert /etc/pccard_ether $device start : remove /etc/pccard_ether $device stop : : : I submitted this to Warner Losh, but IIRC, I got an indication : back that this wasn't right. However, I don't recall that I ever got : any correct pccard.conf setting for this device, and while I could : get FreeBSD to see the card and use this entry to mostly recognize : it, I could not actually get any positive network results this way. : : Any additional information you can find would be appreciated. : Right now, I'm using a Linksys (EtherFast 10/100 Integrated PC Card : (PCM100) on the machine where I was trying to use the Belkin, but it : sticks out from the machine and blocks the second PC Card slot, so : I'd prefer to use the Belkin (which is flush with the edge and comes : with a dongle), if possible. : : If I could get them both working, or get one of them working with : one of my various 802.11b WiFi cards, then I would have two NICs and : could do some much more interesting things with this machine. : Unfortunately, everything seems to want IRQ3, so even if I could get : the individual cards working by themselves, I don't know if I could : ever get them working together. : : : I did find an interesting entry at : http://www.freebsdforums.org/forums/showthread.php?threadid=8315, : at the bottom (dated April 2002) that shows the pccard.conf entry of: : : # Belkin F5D5020 : card Belkin F5D5020-PCMCIA-Network-Card : config auto ed ? 0x10 : insert /etc/pccard_ether $device start : remove /etc/pccard_ether $device stop : : Which the author claims (claimed) works (worked) for him. : : : You can see my posts from October of last year at : http://docs.freebsd.org/cgi/getmsg.cgi?fetch=753513+0+archive/2002/freebsd- questions/20021013.freebsd-questions, : http://docs.freebsd.org/cgi/getmsg.cgi?fetch=2755078+0+archive/2002/freebsd -questions/20021013.freebsd-questions, : and : http://docs.freebsd.org/cgi/getmsg.cgi?fetch=750581+0+archive/2002/freebsd- questions/20021013.freebsd-questions. : And then there's the post at : http://lists.freebsd.org/pipermail/freebsd-questions/2003-April/001987.html : from April, which also mentions this card. : : But still, no answers to this question. Unfortunately, just : Googling for Belkin F5D5020 FreeBSD doesn't do much good, as it : turns up many resellers of this card which claims that it works with : FreeBSD, or articles that happen to mention both FreeBSD and this : card on the same page (such as :
panic: sleeping thread owns a mutex
One of the alpha package machines just died with the following: panic: sleeping thread owns a mutex panic() at panic+0x160 propagate_priority() at propagate_priority+0x148 _mtx_lock_sleep() at _mtx_lock_sleep+0x264 _mtx_lock_flags() at _mtx_lock_flags+0x84 _vm_map_lock() at _vm_map_lock+0x40 vm_map_remove() at vm_map_remove+0x34 kmem_free() at kmem_free+0x34 pipe_free_kmem() at pipe_free_kmem+0xbc pipeclose() at pipeclose+0x188 pipe_close() at pipe_close+0x40 fdrop_locked() at fdrop_locked+0x180 fdrop() at fdrop+0x50 closef() at closef+0x260 fdfree() at fdfree+0x3c4 exit1() at exit1+0x578 sys_exit() at sys_exit+0x58 syscall() at syscall+0x338 XentSys() at XentSys+0x64 --- syscall (1, FreeBSD ELF64, sys_exit) --- --- user mode --- db (gdb -k is still broken on alpha, so I can't do better). The machine is running a kernel from June 20. Kris pgp0.pgp Description: PGP signature
Re: device driver memory leak in 5.1-20030726?
John-Mark Gurney writes: --E/DnYTRukya0zdZ1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Lukas Ertl wrote this message on Mon, Jul 28, 2003 at 01:11 +0200: Then I have no explanation. I'm running the box with a WiFi card, generating lots of network traffic, and the box is running fine, no panics, and low devbuf allocation. I'm running the box with the USB Bluetooth dongle, generating much less traffic (it's just a 9.6kbit GSM link), and the box panics within half an hour in kmem_malloc, with devbuf allocation up to 74MB. It must be either in the Bluetooth code or in the USB code. Upon futher looking at the code, I have a better fix for this. Let me know how things go for you. It appears to me that the test in usb_block_allocmem() should be (p-tag-parent == tag || p-tag-parent == tag-parent) and NOT p-tag == tag! That's because bus_dma_tag_create() uses the tag passed into usb_block_allocmem() as newtag-parent! Unfortunately, bus_dma_tag is an opaque type and there's no way to access the parent member anywhere but in the MD busdma_machdep.c :-( Anyway, as written there's no way that I can see that the code can work correctly. --- Gary Jennejohn / garyj[at]jennejohn.org gj[at]freebsd.org gj[at]denx.de ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
broken world
/usr/src/contrib/isc-dhcp/common/dispatch.c:47: error: syntax error before string constant /usr/src/contrib/isc-dhcp/common/dispatch.c:44:1: unterminated #ifndef *** Error code 1 This error also occurs in isc-dhcp/includes/dhcpd.h:45 an possibly in more files. The source looks like: #ifndef lint $FreeBSD: src/contrib/isc-dhcp/includes/dhcpd.h,v 1.2 2003/07/28 08:30:11 mbr Exp $\n; #endif /* not lint */ This is with a recently cvsupped current. It is probably caused by a commit by mbr about three hours ago. Jilles Tjoelker, Jan Willem Knopper ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: broken world
On Mon, 28 Jul 2003, Jan Willem Knopper wrote: /usr/src/contrib/isc-dhcp/common/dispatch.c:47: error: syntax error before string constant /usr/src/contrib/isc-dhcp/common/dispatch.c:44:1: unterminated #ifndef *** Error code 1 This error also occurs in isc-dhcp/includes/dhcpd.h:45 an possibly in more files. The source looks like: #ifndef lint $FreeBSD: src/contrib/isc-dhcp/includes/dhcpd.h,v 1.2 2003/07/28 08:30:11 mbr Exp $\n; #endif /* not lint */ This was fixed in rev. 1.3 of src/contrib/isc-dhcp/common/dispatch.c. regards, le -- Lukas Ertl eMail: [EMAIL PROTECTED] UNIX Systemadministrator Tel.: (+43 1) 4277-14073 Vienna University Computer Center Fax.: (+43 1) 4277-9140 University of Vienna http://mailbox.univie.ac.at/~le/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: broken world
I should sleep more ! /usr/src/contrib/isc-dhcp/common/dispatch.c:47: error: syntax error before string constant /usr/src/contrib/isc-dhcp/common/dispatch.c:44:1: unterminated #ifndef *** Error code 1 Sorry for the troubles I've caused. Martin ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
savecore options
Hello - savecore and its manpage are missing options. savecore is missing -z and -N from its usage list. savecore manpage is missing -N. Thanks David ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Memory Mangement Problem in 5.1-RELEASE
Ahmed Al-Hindawi wrote: If your system is spending a lot of time moving data to and from swap when it is not memory-starved, or if it is stalling memory allocations that it should be able to fulfill from free RAM, that's a concern. That is exactly it. I emphaises th words when it is not memory-starved . It isn't memory starved. Also I get 150Mb frequently of swap disk space, whilst still having a complete third of my memory free!! I can understand everyones view on this, that the swap algorithim is swaping pre-emtively. But 150MB?? Is that what is called a low level of swaping?? From the set of applications you listed, 150 MB doesn't even sound all that much. 300MB-400MB is the footprint I'd expect for that. -- 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] Weiner's Law of Libraries: There are no answers, only cross references. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Checking buildworld success from ssh
Hi all, I started a buildworld on current sources this morning, but, foolishly, didn't redirect the output to a file. Now I have some free time at work and would like to ssh in and do the kernel and mergemaster. Of course, I don't want to do these things if buildworld failed. Is there any way I can tell in the absence of saved output? Thanks. Greg ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Highly loaded machine getting slower and slower
Hi there, I'm having again problems with a highly loaded 5.1-current machine. The box is a 2.4GHz Dual Xeon (HTT enabled) with 1GB RAM and acts as a news server/feeder running diablo. It's pumping out 120+Mbit/sec over Gigabit without a glitch, but after some time, it's getting slower and slower, until it seems to completely freeze, but it's still alive, just _very_ unresponsive and in fact has to be rebooted. A kernel without WITNESS checks survives a few hours, a kernel with WITNESS and friends stays up longer, but in fact after one, two weeks it's the same picture. If the machine seems to be stuck again and you break into the debugger, you always get something like this: db where _mtx_lock_sleep(c03fa6f0,0,0,0,) at _mtx_lock_sleep+0x1e6 msleep(c21be0ec,c03fa6f0,44,c03ad35b,0) at msleep+0x888 acquire(e3a81a38,100,600,11000,c6f23d10) at acquire+0xbe lockmgr(c21be0ec,2,0,c6f23d10,11000) at lockmgr+0x3f7 _vm_map_lock(c21be0b0,0,0,e3a81a7c,e3a81a84) at _vm_map_lock+0x5d kmem_alloc_wait(c21be0b0,11000,c6f2b4b0,c1618378,120) at kmem_alloc_wait+0x38 kern_execve(c6f23d10,bfbff410,bfbff2fc,bfbffd60,0) at kern_execve+0x219 execve(c6f23d10,e3a81d10,c,c022c1e6,3) at execve+0x30 syscall(2f,2f,2f,bfbff490,bfbff2fc) at syscall+0x2b0 Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (59, FreeBSD ELF32, execve), eip = 0x481132df, esp = 0xbfbff2ec, ebp = 0 378 --- The machine is running about 250+ concurrent diablo/dnewslink processes. Any hints or ideas? regards, le -- Lukas Ertl eMail: [EMAIL PROTECTED] UNIX Systemadministrator Tel.: (+43 1) 4277-14073 Vienna University Computer Center Fax.: (+43 1) 4277-9140 University of Vienna http://mailbox.univie.ac.at/~le/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Highly loaded machine getting slower and slower
In message [EMAIL PROTECTED], Lukas Ertl writes: Hi there, I'm having again problems with a highly loaded 5.1-current machine. The box is a 2.4GHz Dual Xeon (HTT enabled) with 1GB RAM and acts as a news server/feeder running diablo. It's pumping out 120+Mbit/sec over Gigabit without a glitch, but after some time, it's getting slower and slower, until it seems to completely freeze, but it's still alive, just _very_ unresponsive and in fact has to be rebooted. Run a shell script in cron every 5 minutes where you record date sysctl kern.malloc sysctl vm.zone swapinfo ps -axlw and look out for anything which just gobbles up more and more memory. -- 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: Checking buildworld success from ssh
On Mon, Jul 28, 2003 at 09:28:07AM -0400, Gregory Pavelcak wrote: Hi all, I started a buildworld on current sources this morning, but, foolishly, didn't redirect the output to a file. Now I have some free time at work and would like to ssh in and do the kernel and mergemaster. Of course, I don't want to do these things if buildworld failed. Is there any way I can tell in the absence of saved output? The last thing made is creation of the freebsd.cf file. See if it was created in /usr/obj/usr/src/etc/sendmail. Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software Ltd, [EMAIL PROTECTED] FreeBSD committer pgp0.pgp Description: PGP signature
Re: Last inline offenders...
The code in mga_stage.c is externally maintained. Its probably not a
good idea to edit that one.
On Wed, 2003-07-23 at 19:55, Poul-Henning Kamp wrote:
The following patch are my suggestion (already sent to maintainers)
for inlines to remove so we can get under the 2000 limit in GCC on
i386.
Index: dev/aic7xxx/aic79xx_inline.h
===
RCS file: /home/ncvs/src/sys/dev/aic7xxx/aic79xx_inline.h,v
retrieving revision 1.12
diff -u -r1.12 aic79xx_inline.h
--- dev/aic7xxx/aic79xx_inline.h 28 Jun 2003 04:43:19 - 1.12
+++ dev/aic7xxx/aic79xx_inline.h 23 Jul 2003 16:37:59 -
@@ -451,7 +451,7 @@
static __inline void ahd_set_sescb_qoff(struct ahd_softc *ahd, u_int value);
static __inline u_intahd_get_sdscb_qoff(struct ahd_softc *ahd);
static __inline void ahd_set_sdscb_qoff(struct ahd_softc *ahd, u_int value);
-static __inline u_intahd_inb_scbram(struct ahd_softc *ahd, u_int offset);
+static u_int ahd_inb_scbram(struct ahd_softc *ahd, u_int offset);
static __inline u_intahd_inw_scbram(struct ahd_softc *ahd, u_int offset);
static __inline uint32_t
ahd_inl_scbram(struct ahd_softc *ahd, u_int offset);
@@ -664,7 +664,7 @@
ahd_outb(ahd, SDSCB_QOFF+1, (value 8) 0xFF);
}
-static __inline u_int
+static u_int
ahd_inb_scbram(struct ahd_softc *ahd, u_int offset)
{
u_int value;
Index: dev/drm/mga_state.c
===
RCS file: /home/ncvs/src/sys/dev/drm/mga_state.c,v
retrieving revision 1.6
diff -u -r1.6 mga_state.c
--- dev/drm/mga_state.c 25 Apr 2003 01:18:46 - 1.6
+++ dev/drm/mga_state.c 23 Jul 2003 18:33:33 -
@@ -71,7 +71,7 @@
ADVANCE_DMA();
}
-static __inline__ void mga_g200_emit_context( drm_mga_private_t *dev_priv )
+static void mga_g200_emit_context( drm_mga_private_t *dev_priv )
{
drm_mga_sarea_t *sarea_priv = dev_priv-sarea_priv;
drm_mga_context_regs_t *ctx = sarea_priv-context_state;
@@ -97,7 +97,7 @@
ADVANCE_DMA();
}
-static __inline__ void mga_g400_emit_context( drm_mga_private_t *dev_priv )
+static void mga_g400_emit_context( drm_mga_private_t *dev_priv )
{
drm_mga_sarea_t *sarea_priv = dev_priv-sarea_priv;
drm_mga_context_regs_t *ctx = sarea_priv-context_state;
@@ -128,7 +128,7 @@
ADVANCE_DMA();
}
-static __inline__ void mga_g200_emit_tex0( drm_mga_private_t *dev_priv )
+static void mga_g200_emit_tex0( drm_mga_private_t *dev_priv )
{
drm_mga_sarea_t *sarea_priv = dev_priv-sarea_priv;
drm_mga_texture_regs_t *tex = sarea_priv-tex_state[0];
@@ -159,7 +159,7 @@
ADVANCE_DMA();
}
-static __inline__ void mga_g400_emit_tex0( drm_mga_private_t *dev_priv )
+static void mga_g400_emit_tex0( drm_mga_private_t *dev_priv )
{
drm_mga_sarea_t *sarea_priv = dev_priv-sarea_priv;
drm_mga_texture_regs_t *tex = sarea_priv-tex_state[0];
@@ -203,7 +203,7 @@
ADVANCE_DMA();
}
-static __inline__ void mga_g400_emit_tex1( drm_mga_private_t *dev_priv )
+static void mga_g400_emit_tex1( drm_mga_private_t *dev_priv )
{
drm_mga_sarea_t *sarea_priv = dev_priv-sarea_priv;
drm_mga_texture_regs_t *tex = sarea_priv-tex_state[1];
@@ -244,7 +244,7 @@
ADVANCE_DMA();
}
-static __inline__ void mga_g200_emit_pipe( drm_mga_private_t *dev_priv )
+static void mga_g200_emit_pipe( drm_mga_private_t *dev_priv )
{
drm_mga_sarea_t *sarea_priv = dev_priv-sarea_priv;
unsigned int pipe = sarea_priv-warp_pipe;
@@ -274,7 +274,7 @@
ADVANCE_DMA();
}
-static __inline__ void mga_g400_emit_pipe( drm_mga_private_t *dev_priv )
+static void mga_g400_emit_pipe( drm_mga_private_t *dev_priv )
{
drm_mga_sarea_t *sarea_priv = dev_priv-sarea_priv;
unsigned int pipe = sarea_priv-warp_pipe;
Index: dev/drm/r128_state.c
===
RCS file: /home/ncvs/src/sys/dev/drm/r128_state.c,v
retrieving revision 1.6
diff -u -r1.6 r128_state.c
--- dev/drm/r128_state.c 25 Apr 2003 01:18:46 - 1.6
+++ dev/drm/r128_state.c 23 Jul 2003 18:33:33 -
@@ -98,7 +98,7 @@
ADVANCE_RING();
}
-static __inline__ void r128_emit_context( drm_r128_private_t *dev_priv )
+static void r128_emit_context( drm_r128_private_t *dev_priv )
{
drm_r128_sarea_t *sarea_priv = dev_priv-sarea_priv;
drm_r128_context_regs_t *ctx = sarea_priv-context_state;
@@ -140,7 +140,7 @@
ADVANCE_RING();
}
-static __inline__ void r128_emit_masks( drm_r128_private_t *dev_priv )
+static void r128_emit_masks( drm_r128_private_t *dev_priv )
{
drm_r128_sarea_t *sarea_priv = dev_priv-sarea_priv;
drm_r128_context_regs_t *ctx = sarea_priv-context_state;
@@ -174,7 +174,7 @@
ADVANCE_RING();
}
-static __inline__ void
Re: savecore options
On Mon, Jul 28, 2003 at 08:24:12AM -0400, David Hill wrote: Hello - savecore and its manpage are missing options. savecore is missing -z and -N from its usage list. savecore manpage is missing -N. -z is missing, but -N is obsolete and simply results in a usage() message. Does anyone object to actually removing -d and -N from the getopt() list? Who are we trying to maintain compatability with? If it is with -stable then now might be a good time to get rid of them. -- Chad David[EMAIL PROTECTED] www.FreeBSD.org [EMAIL PROTECTED] ISSci Inc.Calgary, Alberta Canada ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cvs commit: src/sys/cam cam_ccb.h src/sys/cam/scsi scsi_cd.cscsi_da.c src/sys/dev/ata atapi-cam.c src/sys/dev/usb umass.csrc/sys/dev/firewire sbp.c
After this code is in both stable and current, current USB quirks will be deprecated but can be re-enabled in a pinch with a kernel option. Unfortunately, I only have contact information for the more recent quirks that were committed and so the only way to find devices that have other problems (i.e. NO_SYNC_CACHE) is to disable the quirks and re-enable them for devices that still fail. Did you ever find the bug in the sync cache silence errors code that was the root cause for most of the quirks? -- Justin ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
NATD question...
All, I am trying to redirect a port on my FreeBSD 5.1-based firewall to an internal machine. My natd configuration contains a directive: redirect-port 192.168.x.x:http I performed a kill -HUP on the natd process, but it doesn't work. I can verify that the internal Web server is functional, and accessible to the internal network. I even added ipfw rules to allow for traffic on port , but still nothing. Am I missing something obvious here? Thanks! -- Paul A. Howes ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
linksys wireless usb adapter
Is there any on going work for this usb network interface? thanks Paulo __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cvs commit: src/sys/cam cam_ccb.h src/sys/cam/scsi scsi_cd.c scsi_da.c src/sys/dev/ata atapi-cam.c src/sys/dev/usb umass.c src/sys/dev/firewire sbp.c
On Mon, 28 Jul 2003, Justin T. Gibbs wrote: After this code is in both stable and current, current USB quirks will be deprecated but can be re-enabled in a pinch with a kernel option. Unfortunately, I only have contact information for the more recent quirks that were committed and so the only way to find devices that have other problems (i.e. NO_SYNC_CACHE) is to disable the quirks and re-enable them for devices that still fail. Did you ever find the bug in the sync cache silence errors code that was the root cause for most of the quirks? Most of the quirks were added for NO_6_BYTE. Many of the USB devices include NO_SYNC_CACHE also although the documentation for many of these was lost before we began keeping PRs documenting the issue. Many of the devices that include NO_SYNC_CACHE were just cut/pasted from previous quirks and no attempt was made to verify the separate need for that quirk. I'll do my best to follow down cvs logs and things but what it comes down to is that we'll just have to test to see what quirks are really needed. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[current tinderbox] failure on alpha/alpha
TB --- 2003-07-28 16:00:03 - starting CURRENT tinderbox run for alpha/alpha TB --- 2003-07-28 16:00:03 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-07-28 16:02:04 - building world TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/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/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/i386/usr/include stage 4: building libraries stage 4: make dependencies stage 4: building everything.. TB --- 2003-07-28 17:08:30 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC Kernel build for GENERIC started on Mon Jul 28 17:08:30 GMT 2003 Kernel build for GENERIC completed on Mon Jul 28 17:20:30 GMT 2003 TB --- 2003-07-28 17:20:30 - generating LINT kernel config TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src/sys/alpha/conf TB --- /usr/bin/make -B LINT TB --- 2003-07-28 17:20:30 - building LINT kernel TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src TB --- /usr/bin/make buildkernel KERNCONF=LINT Kernel build for LINT started on Mon Jul 28 17:20:30 GMT 2003 [...] cc -c -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -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/alpha/alpha/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/advansys/adwlib.c cc -c -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -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/alpha/alpha/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/advansys/adwmcode.c cc -c -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -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/alpha/alpha/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/aha/aha.c cc -c -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -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/alpha/alpha/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror
Re: cvs commit: src/sys/cam cam_ccb.h src/sys/cam/scsi scsi_cd.cscsi_da.c src/sys/dev/ata atapi-cam.c src/sys/dev/usb umass.csrc/sys/dev/firewire sbp.c
Date: Sun, 27 Jul 2003 23:23:33 -0700 (PDT) From: Nate Lawson [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] On Sun, 27 Jul 2003, Nate Lawson wrote: Modified files: sys/cam cam_ccb.h sys/cam/scsi scsi_da.c scsi_cd.c sys/dev/ata atapi-cam.c sys/dev/usb umass.c sys/dev/firewire sbp.c Log: Add a PATH_INQ flag, PIM_NO_6_BYTE, which indicates the SIM never wishes to receive 6 byte commands. Add a check for this flag to da(4) and cd(4) so that they honor it. This is a quick workaround for many devices (especially USB) that require da(4) quirks to operate. The more complete approach is to finish the new transport code which will be aware of the SCSI version a transport implements. MFC after: 1 day Revision ChangesPath 1.26 +2 -1 src/sys/cam/cam_ccb.h 1.80 +8 -0 src/sys/cam/scsi/scsi_cd.c 1.147 +8 -0 src/sys/cam/scsi/scsi_da.c 1.18 +1 -1 src/sys/dev/ata/atapi-cam.c 1.58 +1 -1 src/sys/dev/firewire/sbp.c 1.88 +1 -1 src/sys/dev/usb/umass.c This is the first step to removing many of the da(4) quirks that have accumulated for USB devices. This code should remove the message: READ(6)/WRITE(6) not supported, increasing minimum_cmd_size to 10. It should also fix USB devices which fail when receiving 6 byte commands but do not yet have a quirk. After this code is in both stable and current, current USB quirks will be deprecated but can be re-enabled in a pinch with a kernel option. Unfortunately, I only have contact information for the more recent quirks that were committed and so the only way to find devices that have other problems (i.e. NO_SYNC_CACHE) is to disable the quirks and re-enable them for devices that still fail. I'm doing this as early as possible before 5.2 to get things sorted out and if your device fails at that point, it can be returned to ordinary behavior with a kernel option until I remove it from the deprecated section. This looks great to me. The entire quirks system is a royal pain. It really needs to be driven by an external file so that the kernel does not need a re-compile for every device that requires poking something odd, but eliminating all of the 6 bye/10 byte ones will greatly improve life. I know such things (like pccard.conf) are ugly, but it's better than patching the source and re-building the kernel all of the time. There must be a better way. Almost anything like this that I plug into Windows just works. That means no driver installation or anything. (The USB devices almost always include software, but I seldom install it.) I just HATE it when Windows works better than FreeBSD, but hardware can be a tough nut to crack. Is there any hope of getting PR53094 to support the Nomad MuVo moved to current. It will still need a quirk as it requires both NO_SYNC_CACHE and NO_PREVENT. The pr has been around for some time but was just assigned to joe@ about 10 days ago, so it may already be on it's way. (I am about 250 messages behind in cvs-all, so it may already have been committed.) -- 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: cvs commit: src/sys/cam cam_ccb.h src/sys/cam/scsi scsi_cd.csrc/sys/dev/firewire sbp.c
On Mon, 28 Jul 2003, Kevin Oberman wrote: From: Nate Lawson [EMAIL PROTECTED] This is the first step to removing many of the da(4) quirks that have accumulated for USB devices. This code should remove the message: READ(6)/WRITE(6) not supported, increasing minimum_cmd_size to 10. It should also fix USB devices which fail when receiving 6 byte commands but do not yet have a quirk. After this code is in both stable and current, current USB quirks will be deprecated but can be re-enabled in a pinch with a kernel option. Unfortunately, I only have contact information for the more recent quirks that were committed and so the only way to find devices that have other problems (i.e. NO_SYNC_CACHE) is to disable the quirks and re-enable them for devices that still fail. I'm doing this as early as possible before 5.2 to get things sorted out and if your device fails at that point, it can be returned to ordinary behavior with a kernel option until I remove it from the deprecated section. This looks great to me. The entire quirks system is a royal pain. It really needs to be driven by an external file so that the kernel does not need a re-compile for every device that requires poking something odd, but eliminating all of the 6 bye/10 byte ones will greatly improve life. I know such things (like pccard.conf) are ugly, but it's better than patching the source and re-building the kernel all of the time. An external file is unnecessary since true quirks are a one-time thing. User finds device is broken and then a quirk is committed. For the USB case, false quirks were needed in that the devices weren't 100% broken, just that they crash when receiving 6 byte cmds instead of returning cmd not supported. The real problem was that we were sending 6 byte commands to devices which we should have known might not be able to handle them (i.e. USB). I'm just fixing the false quirk case (which should be 90% of our USB quirks). These false quirks were adding tons of noise and masking truly broken devices (which should be in the minority). Committing such quirks should go faster once there is less chaff to deal with. There must be a better way. Almost anything like this that I plug into Windows just works. That means no driver installation or anything. (The USB devices almost always include software, but I seldom install it.) I just HATE it when Windows works better than FreeBSD, but hardware can be a tough nut to crack. Linux still lists broken USB devices in a kernel file. Is there any hope of getting PR53094 to support the Nomad MuVo moved to current. It will still need a quirk as it requires both NO_SYNC_CACHE and NO_PREVENT. The pr has been around for some time but was just assigned to joe@ about 10 days ago, so it may already be on it's way. (I am about 250 messages behind in cvs-all, so it may already have been committed.) I'll look at the PR. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Checking buildworld success from ssh
Hi, you could restart the buildworld with the -DNOCLEAN option, this would terminate much faster than usual o r show up where it fails.. Hope this helps. Regards Henry Am Montag, 28.07.03, um 15:28 Uhr (Europe/Berlin) schrieb Gregory Pavelcak: Hi all, I started a buildworld on current sources this morning, but, foolishly, didn't redirect the output to a file. Now I have some free time at work and would like to ssh in and do the kernel and mergemaster. Of course, I don't want to do these things if buildworld failed. Is there any way I can tell in the absence of saved output? ... ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dereferencing type-punned pointer will break strict-aliasingrules
Apparently, On Mon, Jul 28, 2003 at 03:59:00AM +0200,
Thomas Moestl said words to the effect of;
On Mon, 2003/07/28 at 09:30:08 +0900, Jun Kuriyama wrote:
Is this caused by -oS option?
- in making BOOTMFS in make release
cc -c -Os -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions
-std=c99 -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/dev
-I/usr/src/sys/contrib/dev/acpica -I/usr/src/sys/contrib/ipfilter
-I/usr/src/sys/contrib/dev/ath -I/usr/src/sys/contrib/dev/ath/freebsd -D_KERNEL
-include opt_global.h -fno-common -finline-limit=15000 -mno-align-long-strings
-mpreferred-stack-boundary=2 -ffreestanding -Werror /usr/src/sys/geom/geom_dev.c
/usr/src/sys/geom/geom_dev.c: In function `g_dev_open':
/usr/src/sys/geom/geom_dev.c:198: warning: dereferencing type-punned pointer will
break strict-aliasing rules
[...]
Yes, by implying -fstrict-aliasing, so using -fno-strict-aliasing is a
workaround. The problem is caused by the i386 PCPU_GET/PCPU_SET
implementation:
#define __PCPU_GET(name) ({ \
__pcpu_type(name) __result; \
\
[...]
} else if (sizeof(__result) == 4) { \
u_int __i; \
__asm __volatile(movl %%fs:%1,%0 \
: =r (__i)\
: m (*(u_int *)(__pcpu_offset(name; \
__result = *(__pcpu_type(name) *)__i; \
[...]
In this case, the PCPU_GET is used to retrieve curthread, causing
sizeof(__result) to be 4, so the cast at the end of the code snippet
is from a u_int * to struct thread *, and __i is accessed through the
casted pointer, which violates the C99 aliasing rules.
An alternative is to type-pun via a union, which is also a bit ugly,
but explicitly allowed by C99. Patch attached (but only superficially
tested).
- Thomas
...
Using a union sounds fine to me.
Jake
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NATD question...
Hi, On Mon, 28 Jul 2003 12:17:24 -0400, Paul A. Howes [EMAIL PROTECTED] said: All, I am trying to redirect a port on my FreeBSD 5.1-based firewall to an internal machine. My natd configuration contains a directive: redirect-port 192.168.x.x:http I performed a kill -HUP on the natd process, but it doesn't work. I can verify that the internal Web server is functional, and accessible to the internal network. I even added ipfw rules to allow for traffic on port , but still nothing. Am I missing something obvious here? Thanks! That's a wrong directive. Use ``redirect_port''. ^ -- rushani ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: device driver memory leak in 5.1-20030726?
Gary Jennejohn wrote this message on Mon, Jul 28, 2003 at 12:58 +0200: It appears to me that the test in usb_block_allocmem() should be (p-tag-parent == tag || p-tag-parent == tag-parent) and NOT p-tag == tag! That's because bus_dma_tag_create() uses the tag passed into usb_block_allocmem() as newtag-parent! Unfortunately, bus_dma_tag is an opaque type and there's no way to access the parent member anywhere but in the MD busdma_machdep.c :-( Anyway, as written there's no way that I can see that the code can work correctly. You miss the code in the XXX bit that overrides the tag with the tag passed in. If we allocate a fullblock, the tag doesn't need to be overwriten since we end up freeing it, but in the fragment case, we override the tag, and we don't need to keep the tag allocated by usb_block_allocmem since we never end up freeing the block that is part of the fragments. The bug fixed in rev1.2 was because of a difference in how NetBSD/OpenBSD handles things. We wouldn't need this if we had a size parameter to bus_dmamem_alloc. Please reread the code and see what I mean. -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SSH from host to jail
--On Sunday, July 27, 2003 16:28:44 -0500 Jon Disnard
[EMAIL PROTECTED] wrote:
Pat Lashley wrote:
I'm trying to set up some jails in a 5.1R system. I've pretty much
copied a setup that was working fine in 4.8; but on 5.1 I can't seem
to SSH from the host system into one of its jails. It acts like the
packets just aren't getting through.
I would really appreciate it if somebody would send me rc.conf fragments
that are known to work for setting up a jail's IP alias and routing on
5.1.
sure, but this isn't going to fix your problem:
ifconfig_wi0=inet 192.168.0.140 netmask 255.255.255.0
ifconfig_wi0_alias0=inet 192.168.0.131 netmask 255.255.255.255
jail_enable=YES
jail_list=shiba
jail_shiba_hostname=shiba
jail_shiba_ip=192.168.0.131
jail_shiba_rootdir=/usr/prison/192_168_0_130/
jail_shiba_exec=/bin/sh /etc/rc
Thanks, but this isn't the part I'm interested in. It looks like
what I need is the stuff that sets up the IP alias, routing, etc.
for the jail. The ifconfig_*_alias* and any route_* or related
rc.conf entries.
To fix your problem you should try to mount a devfs for the jail so the
tty device is available for sshd to open when you login. I simply added
one line to my /etc/rc.d/jail script to test for the dev mount-point in
jail. Like so:
Nope, I had a devfs set up.
Note that I'm still getting them set up; so I'm starting them by hand
instead of using the rc script. (Well, actually, I'll use an updated
version of the script I was using on 4.8 because I have some additional
work I want done there and I don't want to start the jails until after
the stuff in /usr/local/etc/rc.d have been run.)
It could be easy to have it simply exist, or be non-null, to imply a
desire for devfs, and further checked for the existence of the
mount-point as I wrote above.
I could have a pr+patch made in 5 minutes if anybody thinks this is not a
bad idea?
Sounds good to me. And a similar patch for procfs.
Or perhaps some more generic solution that would allow for open-ended
additional mounts?
jail_mumble_mounts='/etc/fstab.mumble'
Then in the loop in /etc/rc.d/jail:
eval jail_fstab=\$jail_${_jail}_mounts\
[ -n $jail_fstab ] mount -a -F $jail_fstab
Note that fstab.mumble is outside the jail; and should only contain
entries for devfs, procfs, and other mounts to be done on top of the
jail before starting it.
-Pat
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SSH from host to jail
--On Monday, July 28, 2003 13:25:07 +0400 Artem 'Zazoobr' Ignatjev [EMAIL PROTECTED] wrote: Errr... Random shot: Have you told ssh on host not to listen on all addresses it'll find? I use 'ListenAddress' directive in /etc/ssh/sshd_config Yes, I have. And if that were the problem, I would expect the SSH session to connect; but to log me into the host system instead of the jail. My actual symptoms are more like the packets just arent' getting there at all. Or maybe aren't getting back... Hmmm. Now it's working. I'd swear that I'm doing exactly the same thing I was trying before; and nothing else has changed. Sigh. Call it pilot error.. -Pat ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Another LOR with filedesc structure and Giant
On Mon, Jul 28, 2003 at 11:09:55AM -0400, Robert Watson wrote: On Sun, 27 Jul 2003, Kris Kennaway wrote: After upgrading last night, one of the package machines found this: I've bumped into some similar problems -- it's a property of how we current lock select(). We hold the file descriptor lock for the duration of polling each object being selected, and if any of those objects has to grab a lock for any reason, it has to implicitly fall after the file descriptor lock. I actually run into this in some of our MAC code, because I need to grab a vnode lock to authorize polling the vnode using VOP_POLL(), and since the vnode lock is a sleep lock, this generates a WITNESS warning. Unfortunately, it's not immediately clear what a better locking scheme would look like without going overboard on the fine-grained side. We probably need to grab Giant before entering the select code since it's highly likely something in there will require Giant -- it reaches down into VFS, the device stuff, socket code, tc. Also lock order reversal 1st 0xc6a69634 filedesc structure (filedesc structure) @ /a/asami/portbuild/i386/src-client/sys/kern/sys_generic.c:1071 2nd 0xc04aa120 Giant (Giant) @ /a/asami/portbuild/i386/src-client/sys/fs/specfs/spec_vnops.c:372 Stack backtrace: backtrace(c043d4af,c04aa120,c0439aa4,c0439aa4,c0434e3d) at backtrace+0x17 witness_lock(c04aa120,8,c0434e3d,174,246) at witness_lock+0x672 _mtx_lock_flags(c04aa120,0,c0434e3d,174,c043daba) at _mtx_lock_flags+0xba spec_poll(d8dfcb44,d8dfcb64,c02d119c,d8dfcb44,c04939a0) at spec_poll+0x134 spec_vnoperate(d8dfcb44,c04939a0,c52cfa44,41,c6cfd280) at spec_vnoperate+0x18 vn_poll(c45dc880,41,c6cfd280,c5f7a4c0,c6cfd280) at vn_poll+0x3c pollscan(c5f7a4c0,d8dfcbd4,2,3e7,10) at pollscan+0xb0 poll(c5f7a4c0,d8dfcd10,c0455899,3ee,3) at poll+0x252 syscall(2f,2f,2f,0,2) at syscall+0x273 Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (209), eip = 0x281c4934, esp = 0xbfbfeee4, ebp = 0xbfbfef20 --- Debugger(witness_lock) Stopped at Debugger+0x54: xchgl %ebx,in_Debugger.0 db Kris pgp0.pgp Description: PGP signature
buffers remaining...
If you boot into single user mode (boot -s), do an fsck (a full fsck, no
options), then halt(8), you will get:
syncing disks, buffers remaining... 1 1 1 1 1 1 1 1 1 1
giving up on 1 buffers
every time. Only happens with clean disks. 100% reproducable.
I have UFS1 partitions. Been happening for quite a while (since 5.0)
--
:{ [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]
Re: Another LOR with filedesc structure and Giant
On Mon, Jul 28, 2003 at 02:53:12PM -0700, Kris Kennaway wrote:
On Mon, Jul 28, 2003 at 11:09:55AM -0400, Robert Watson wrote:
On Sun, 27 Jul 2003, Kris Kennaway wrote:
After upgrading last night, one of the package machines found this:
I've bumped into some similar problems -- it's a property of how we
current lock select(). We hold the file descriptor lock for the duration
of polling each object being selected, and if any of those objects has
to grab a lock for any reason, it has to implicitly fall after the file
descriptor lock. I actually run into this in some of our MAC code,
because I need to grab a vnode lock to authorize polling the vnode using
VOP_POLL(), and since the vnode lock is a sleep lock, this generates a
WITNESS warning. Unfortunately, it's not immediately clear what a better
locking scheme would look like without going overboard on the fine-grained
side. We probably need to grab Giant before entering the select code
since it's highly likely something in there will require Giant -- it
reaches down into VFS, the device stuff, socket code, tc.
Also
lock order reversal
1st 0xc6a69634 filedesc structure (filedesc structure) @
/a/asami/portbuild/i386/src-client/sys/kern/sys_generic.c:1071
2nd 0xc04aa120 Giant (Giant) @
/a/asami/portbuild/i386/src-client/sys/fs/specfs/spec_vnops.c:372
Stack backtrace:
backtrace(c043d4af,c04aa120,c0439aa4,c0439aa4,c0434e3d) at backtrace+0x17
witness_lock(c04aa120,8,c0434e3d,174,246) at witness_lock+0x672
_mtx_lock_flags(c04aa120,0,c0434e3d,174,c043daba) at _mtx_lock_flags+0xba
spec_poll(d8dfcb44,d8dfcb64,c02d119c,d8dfcb44,c04939a0) at spec_poll+0x134
spec_vnoperate(d8dfcb44,c04939a0,c52cfa44,41,c6cfd280) at spec_vnoperate+0x18
vn_poll(c45dc880,41,c6cfd280,c5f7a4c0,c6cfd280) at vn_poll+0x3c
pollscan(c5f7a4c0,d8dfcbd4,2,3e7,10) at pollscan+0xb0
poll(c5f7a4c0,d8dfcd10,c0455899,3ee,3) at poll+0x252
syscall(2f,2f,2f,0,2) at syscall+0x273
Xint0x80_syscall() at Xint0x80_syscall+0x1d
#8 0xc0290ed7 in witness_lock (lock=0xc04aa120, flags=8,
file=0xc0434e3d /a/asami/portbuild/i386/src-client/sys/fs/specfs/spec_vnops.c,
line=372)
at /a/asami/portbuild/i386/src-client/sys/kern/subr_witness.c:838
#9 0xc0261f4a in _mtx_lock_flags (m=0x0, opts=0, file=0xc04d1818 , line=-1068850912)
at /a/asami/portbuild/i386/src-client/sys/kern/kern_mutex.c:334
#10 0xc0231154 in spec_poll (ap=0xd8dfcb44)
at /a/asami/portbuild/i386/src-client/sys/fs/specfs/spec_vnops.c:372
#11 0xc0230648 in spec_vnoperate (ap=0x0)
at /a/asami/portbuild/i386/src-client/sys/fs/specfs/spec_vnops.c:122
#12 0xc02d119c in vn_poll (fp=0x0, events=0, active_cred=0xc6cfd280, td=0x0) at
vnode_if.h:537
#13 0xc0294c50 in pollscan (td=0xc5f7a4c0, fds=0xd8dfcbdc, nfd=2)
at /a/asami/portbuild/i386/src-client/sys/sys/file.h:272
#14 0xc02948a2 in poll (td=0xc5f7a4c0, uap=0xd8dfcd10)
at /a/asami/portbuild/i386/src-client/sys/kern/sys_generic.c:1001
#15 0xc03ef9b3 in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 0, tf_esi = 2, tf_ebp =
-1077940448, tf_isp = -656421516, tf_ebx = 673224876, tf_edx = 139153408, tf_ecx =
137314336, tf_eax = 209, tf_trapno = 0, tf_err = 2, tf_eip = 672942388, tf_cs = 31,
tf_eflags = 659, tf_esp = -1077940508, tf_ss = 47})
at /a/asami/portbuild/i386/src-client/sys/i386/i386/trap.c:1008
#16 0xc03dfbed in Xint0x80_syscall () at {standard input}:144
---Can't read userspace from dump, or kernel process---
Kris
pgp0.pgp
Description: PGP signature
RE: NATD question...
I typed that wrong in the e-mail, but not in my configuration file. redirect_port 192.168.x.x:http The question still stands: Why didn't this work? Thanks! -- Paul A. Howes -Original Message- From: Hideyuki KURASHINA [mailto:[EMAIL PROTECTED] Sent: Monday, July 28, 2003 3:53 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: NATD question... Hi, On Mon, 28 Jul 2003 12:17:24 -0400, Paul A. Howes [EMAIL PROTECTED] said: All, I am trying to redirect a port on my FreeBSD 5.1-based firewall to an internal machine. My natd configuration contains a directive: redirect-port 192.168.x.x:http I performed a kill -HUP on the natd process, but it doesn't work. I can verify that the internal Web server is functional, and accessible to the internal network. I even added ipfw rules to allow for traffic on port , but still nothing. Am I missing something obvious here? Thanks! That's a wrong directive. Use ``redirect_port''. ^ -- rushani ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NATD question...
On Mon, 28 Jul 2003 18:54:17 -0400, Paul A. Howes [EMAIL PROTECTED] said: I typed that wrong in the e-mail, but not in my configuration file. redirect_port 192.168.x.x:http The question still stands: Why didn't this work? Strange. It may take some minutes to reflect your natd config file. If you want to take effect of your change immediately, kill -TERM natd process and then perform /sbin/natd -f config.file. -- rushani ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Fwd: new search tool for FreeBSD community
Dear Sir(s), Rambler (www.rambler.ru) developed new search tool working with FreeBSD project mail archives. You can try it at http://freebsd.rambler.ru/ Index contains messages from all mail archives including cvs commits, bug reports, etc. We plan to update database daily. Any comments, suggestions, bug-reports welcome. Best regards, Vladislav Shabanov, Rambler e-mail: [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
HEADSUP: USB da(4) quirks deprecated
I have committed code to disable the USB and Firewire quirks in da(4). Since we now have code that should handle the common case of a failure after receiving 6 byte commands, most of them should no longer be necessary. However, the only way to tell if a quirk is really needed is to test the new code with the quirks disabled. You may have a device (USB camera, pen drive, hard drive, ...) that begins to get errors like BBB bulk-in clear stall failed or Synchronize cache failed, status 0x35. If you get these, you can enable previous behavior by adding: options DA_OLD_QUIRKS to your kernel config and recompiling. Once you do this, please send me the output of camcontrol inquiry da0 so I can re-enable your quirk for good. I'm doing this as soon as possible so the unnecessary quirks can be removed for 5.2. A similar process will take place in 4-stable after 5.2 has been released. Thanks for your patience, Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
fixed another leak in USB code
Ok, those of you coming with panics due to kmem exhaustion w/ USB, I have fixed another leak. For some reason I assumed that big blocks were being deallocated upon free, not being put back on the freelist. (Have I mentioned how much it sucks that the USB code it self has five different allocators?) As mentioned in the commit message, I did some testing, and a simple bulk transfer over aue did not increase the devbuf memory usage, while before this patch, I got it quickly over 20megs and growing. Sorry for the breakage. -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADSUP: USB da(4) quirks deprecated
Hi, camcontrol inquiry requires the pass driver, so if it's not already in your kernel config you might want to add it when/if you add DA_OLD_QUIRKS. Regards, Andre Guibert de Bruet | Enterprise Software Consultant Silicon Landmark, LLC. | http://siliconlandmark.com/ On Mon, 28 Jul 2003, Nate Lawson wrote: I have committed code to disable the USB and Firewire quirks in da(4). Since we now have code that should handle the common case of a failure after receiving 6 byte commands, most of them should no longer be necessary. However, the only way to tell if a quirk is really needed is to test the new code with the quirks disabled. You may have a device (USB camera, pen drive, hard drive, ...) that begins to get errors like BBB bulk-in clear stall failed or Synchronize cache failed, status 0x35. If you get these, you can enable previous behavior by adding: options DA_OLD_QUIRKS to your kernel config and recompiling. Once you do this, please send me the output of camcontrol inquiry da0 so I can re-enable your quirk for good. I'm doing this as soon as possible so the unnecessary quirks can be removed for 5.2. A similar process will take place in 4-stable after 5.2 has been released. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[current tinderbox] failure on alpha/alpha
TB --- 2003-07-29 04:00:04 - starting CURRENT tinderbox run for alpha/alpha TB --- 2003-07-29 04:00:04 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-07-29 04:08:19 - building world TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/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/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/i386/usr/include stage 4: building libraries stage 4: make dependencies stage 4: building everything.. TB --- 2003-07-29 05:14:03 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC Kernel build for GENERIC started on Tue Jul 29 05:14:03 GMT 2003 Kernel build for GENERIC completed on Tue Jul 29 05:25:52 GMT 2003 TB --- 2003-07-29 05:25:52 - generating LINT kernel config TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src/sys/alpha/conf TB --- /usr/bin/make -B LINT TB --- 2003-07-29 05:25:52 - building LINT kernel TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src TB --- /usr/bin/make buildkernel KERNCONF=LINT Kernel build for LINT started on Tue Jul 29 05:25:52 GMT 2003 [...] cc -c -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -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/alpha/alpha/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/advansys/adwlib.c cc -c -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -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/alpha/alpha/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/advansys/adwmcode.c cc -c -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -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/alpha/alpha/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/aha/aha.c cc -c -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -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/alpha/alpha/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror
