Re: panic: mutex tty owned at ../../../kern/kern_event.c:1487
Dan Nelson wrote this message on Sat, Apr 23, 2005 at 22:52 -0500: In the last episode (Apr 23), John-Mark Gurney said: Dan Nelson wrote this message on Sat, Apr 23, 2005 at 12:28 -0500: Got the following on a 2004-04-21 -stable kernel: panic messages: --- panic: mutex tty owned at ../../../kern/kern_event.c:1487 cpuid = 0 I can whip up a patch if you want to try it (and can easily reproduce)... I tried repeating the panic (hitting ^C in an app partway through its startup routine), but it's not cooperating, unfortunately. it's a very tight race.. basicly a second character has to come in between the time the first one happens, and before the test for the PENDIN flag happens... most likely to occure over an ssh pty that has a program using kqueue.. -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Headsup: USB MFCs to 4.x
Julian Elischer [EMAIL PROTECTED] wrote: I have just merged in most of the lowest level changes to 4.x from 6.x. Thank you very much! It's very good to see such important updates in RELENG_4, despite the existance of RELENG_5. If you use USB on 4.x machines and are planning on following RELENG_4 then I suggest you test the latest sources to avoid nasty surprises later. I do follow RELENG_4. Unfortunately I'm currently in the process of moving to a new flat, so I have zero time for testing right now. I will probably merge some of the actual device drivers as well, though I have limited resources for testing them.. Maybe my USB modem will work one day. For the time being I'm using a good old serial (RS232) modem (fortunately my notebook still has an RS232 serial port). I'll test it as soon as I have the time, and report the results. Thanks again for your work, it's really appreciated! Best regards Oliver -- Oliver Fromme, secnetix GmbH Co KG, Oettingenstr. 2, 80538 München Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. Python tricks is a tough one, cuz the language is so clean. E.g., C makes an art of confusing pointers with arrays and strings, which leads to lotsa neat pointer tricks; APL mistakes everything for an array, leading to neat one-liners; and Perl confuses everything period, making each line a joyous adventure wink. -- Tim Peters ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
I386_GET_FSBASE?
I'm building a recent RELENG_5 from source and have the following error: /usr/src/lib/libc/i386/sys/i386_get_fsbase.c: In function `i386_get_fsbase': /usr/src/lib/libc/i386/sys/i386_get_fsbase.c:36: error: `I386_GET_FSBASE' undeclared (first use in this function) /usr/src/lib/libc/i386/sys/i386_get_fsbase.c:36: error: (Each undeclared identifier is reported only once /usr/src/lib/libc/i386/sys/i386_get_fsbase.c:36: error: for each function it appears in.) *** Error code 1 Any idea how to cure it? 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. = pgpYBIqd7F05k.pgp Description: PGP signature
Re: UPDATE: ATA mkIII official patches for releng_5
Any clues at all? I'd *really* like to apply the patches to my system, but continuously run into that kmod.mk problem. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: UPDATE: ATA mkIII official patches for releng_5
El Jueves, 28 de Abril de 2005 11:30, Damian Gerow escribió: Any clues at all? I'd *really* like to apply the patches to my system, but continuously run into that kmod.mk problem. Using this in RELENG_5_4 without problems. latest -n patchset. look into the list archive for the sos announce. -- josemi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dell PowerEdge 1855
Hi Doug, Sorry for taking so long to reply on this, been on 3 weeks leave... On Fri, 8 Apr 2005, Doug White wrote: On Wed, 6 Apr 2005, Carl Makin wrote: The boot sequence will hang if the USB drive is attached at boot. There It seems to be acting like Uthe USB controller isn't getting interrupts. Does the problem recur on the installed system? Yes it did however that chassis and the servers were a test loaner and have been returned. We have decided to go with the 1855 though (our windows guy was *very* enthusiastic about them) and when they arrive I'll run the tests you suggested. Thanks! Carl. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
MFC pxe fixes
Hi, I note that the long standing bug that prevents do a nfsroot mount after operate pxeloader in tftp mode is recent solved in -CURRENT pxe.c I think this can be missed for 5.4 REL, but I'll be glad to see this MFC as time permitting. thanks in advance, -- josemi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: UPDATE: ATA mkIII official patches for releng_5
Thus spake Jose M Rodriguez ([EMAIL PROTECTED]) [28/04/05 06:10]: : Any clues at all? I'd *really* like to apply the patches to my : system, but continuously run into that kmod.mk problem. : : Using this in RELENG_5_4 without problems. latest -n patchset. look : into the list archive for the sos announce. I'm using the latest -n patchset. I tried against RELENG_5_4, and against a RELENG_5 sup from last night. I still get the kmod.mk build error. I'm positive it's something about my build environment, but I don't know /what/. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: UPDATE: ATA mkIII official patches for releng_5
El Jueves, 28 de Abril de 2005 17:41, Damian Gerow escribió: Thus spake Jose M Rodriguez ([EMAIL PROTECTED]) [28/04/05 06:10]: : Any clues at all? I'd *really* like to apply the patches to my : system, but continuously run into that kmod.mk problem. : : Using this in RELENG_5_4 without problems. latest -n patchset. : look into the list archive for the sos announce. I'm using the latest -n patchset. I tried against RELENG_5_4, and against a RELENG_5 sup from last night. I still get the kmod.mk build error. I'm positive it's something about my build environment, but I don't know /what/. For safety, and only about what I'm using (RELENG_5_4), you: - cvs/cvsup fresh sources - apply the patchset - untar the tarball And get what build error? -- josemi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: UPDATE: ATA mkIII official patches for releng_5
Thus spake Jose M Rodriguez ([EMAIL PROTECTED]) [28/04/05 12:32]: : I'm positive it's something about my build environment, but I don't : know /what/. : : For safety, and only about what I'm using (RELENG_5_4), you: : - cvs/cvsup fresh sources : - apply the patchset : - untar the tarball : : And get what build error? # rm -rf /usr/src # cvsup -g /etc/stable-supfile /dev/null # cd /usr/src # patch -p0 ~/ata-mk3n.diff-releng5 snip # tar -zxf ~/ata-mk3n-releng5.tar.gz # make buildkernel KERNCONF=GENERIC -- Kernel build for GENERIC started on Thu Apr 28 13:04:42 EDT 2005 -- === GENERIC mkdir -p /usr/obj/usr/src/sys snip === ata/atapci /usr/src/sys/modules/ata/atapci/../../../conf/kmod.mk, line 311: if-less endif /usr/src/sys/modules/ata/atapci/../../../conf/kmod.mk, line 311: Need an operator /usr/src/sys/modules/ata/atapci/../../../conf/kmod.mk, line 311: if-less endif /usr/src/sys/modules/ata/atapci/../../../conf/kmod.mk, line 311: Need an operator /usr/src/sys/modules/ata/atapci/../../../conf/kmod.mk, line 313: Need an operator /usr/src/sys/modules/ata/atapci/../../../conf/kmod.mk, line 311: if-less endif /usr/src/sys/modules/ata/atapci/../../../conf/kmod.mk, line 311: Need an operator /usr/src/sys/modules/ata/atapci/../../../conf/kmod.mk, line 313: Need an operator /usr/src/sys/modules/ata/atapci/../../../conf/kmod.mk, line 325: Need an operator Makefile, line 9: 1 open conditional: Makefile, line 9: at line 315 (evaluated to true) make: fatal errors encountered -- cannot continue *** Error code 1 Stop in /usr/src/sys/modules/ata. *** Error code 1 Stop in /usr/src/sys/modules. *** Error code 1 Stop in /usr/obj/usr/src/sys/GENERIC. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. # And yes, if I do a 'make buildworld' beforehand, I get the same error. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
fsck_ufs: cannot increase directory list
I rebooted my server, and fsck'ed the disks, and here's what I get: # fsck -y /vol1 ** /dev/da0s1d ** Last Mounted on /vol1 ** Phase 1 - Check Blocks and Sizes fsck_ufs: cannot increase directory list # df -i Filesystem 1K-blocksUsed Avail Capacity iused ifree %iused Mounted on /dev/da0s1d1891668564 1643042028 9729305294% 32927755 211542003 13% /vol1 What's wrong? It lets me mount it rw and ro, but I'm afraid data is going to get corrupt. Eric -- Eric AndersonSr. Systems AdministratorCentaur Technology A lost ounce of gold may be found, a lost moment of time never. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SATA RAID 1 controllers for Intel board
Please do not top post. Apologies - I'll try to be more diligent about that. I was gonna say just define the array beforehand and use the latest 6.x snapshot ISO (http://www.freebsd.org/snapshots/), but it looks like ATA mkIII didn't make it into the tree until 2 weeks after the last snapshot. Until the next snapshot is built it looks like you're stuck using the procedure Samuel described. You could also create your own install media from -CURRENT, but thats a tad more involved, but it will yield you a bootable media that you can use to install directly onto the RAID from. -Sam ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: UPDATE: ATA mkIII official patches for releng_5
On 4/28/05, Damian Gerow [EMAIL PROTECTED] wrote: I'm using the latest -n patchset. I tried against RELENG_5_4, and against a RELENG_5 sup from last night. I still get the kmod.mk build error. I'm positive it's something about my build environment, but I don't know /what/. If you modified your /etc/make.conf, try commenting all your changes out. Or post a copy here so someone can see if there is a problem in your make.conf file. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: UPDATE: ATA mkIII official patches for releng_5
On 4/28/05, Scot Hetzel [EMAIL PROTECTED] wrote: On 4/28/05, Damian Gerow [EMAIL PROTECTED] wrote: I'm using the latest -n patchset. I tried against RELENG_5_4, and against a RELENG_5 sup from last night. I still get the kmod.mk build error. I'm positive it's something about my build environment, but I don't know /what/. If you modified your /etc/make.conf, try commenting all your changes out. Or post a copy here so someone can see if there is a problem in your make.conf file. Didn't notice your earlier post about your make.conf file. Look at the ata/Makefile and make sure there are no lines like: : : As this indicates a conflict is in the file, and you'll need to fix it. Scot ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB changes.
+++ Currently, I find my P4 hanging just after discovering the parallel port and mounting disk; in other words, just here: ppc0: parallel port not found. ad0: 28629MB ST330620A [58168/16/63] at ata0-master UDMA100 but -only- when my Logitech USB mouse is plugged in. Now, if I unplug it and hit reset (not Ctrl-Alt-Del; the keyboard is frozen) the system boots, and I can obtain X w/ a functional mouse. Yesterday, of course, prior to the USB change the system did not hang. I saw this problem in testing ad THOUGHT I had checked in the fix.. Can you confirm that usb.c ends with: SYSINIT(usb_cold_explore, SI_SUB_INT_CONFIG_HOOKS, SI_ORDER_FIRST, usb_cold_explore, NULL); I noticed that some code was changed in between my discovery of the hanging and my attempt to fix it: Apr 27 21:15 subr_bus.c but this change, and the subsequent world update, did not solve the issue of the hanging mouse. the changes that you are refering to include some to defer probing of the USB 1.1 busses untill after the USB2.0 busses have been configured. They should probe for the devices at around the same time that the scsi devices probe. I'll see if I can duplicate yuor problem.. I tested with several USB 1.1 devices but a mounse was not amongst them. See, I know I've only myself to blame for missing the announcement and/or starting an upgrade in an interstice between stability and apparent instability. But still...test first, deploy later, perhaps? Kernel bits, had them for a couple of years now: device uhci device ohci device ehci device usb device ugen device ums device uscanner With my luck, it's probably not the mouse after all. I assume it works right if you remove the mouse before booting and reinsert it after the kernel has booted? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: UPDATE: ATA mkIII official patches for releng_5
Thus spake Scot Hetzel ([EMAIL PROTECTED]) [28/04/05 14:21]: : Look at the ata/Makefile and make sure there are no lines like: : : : : : : : : : : As this indicates a conflict is in the file, and you'll need to fix it. Nope. All patches applied without problems. Makefile and Makefile.inc (and that which Makefile.inc includes) all look clean to me. My kmod.mk is the same as one on a working system. I'm at a loss. - Damian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: UPDATE: ATA mkIII official patches for releng_5
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 4/28/2005 12:05 PM, Damian Gerow wrote: Thus spake Jose M Rodriguez ([EMAIL PROTECTED]) [28/04/05 12:32]: : I'm positive it's something about my build environment, but I don't : know /what/. : : For safety, and only about what I'm using (RELENG_5_4), you: : - cvs/cvsup fresh sources : - apply the patchset : - untar the tarball : : And get what build error? # rm -rf /usr/src # cvsup -g /etc/stable-supfile /dev/null # cd /usr/src # patch -p0 ~/ata-mk3n.diff-releng5 snip # tar -zxf ~/ata-mk3n-releng5.tar.gz # make buildkernel KERNCONF=GENERIC -- Kernel build for GENERIC started on Thu Apr 28 13:04:42 EDT 2005 -- === GENERIC mkdir -p /usr/obj/usr/src/sys snip === ata/atapci /usr/src/sys/modules/ata/atapci/../../../conf/kmod.mk, line 311: if-less endif /usr/src/sys/modules/ata/atapci/../../../conf/kmod.mk, line 311: Need an operator /usr/src/sys/modules/ata/atapci/../../../conf/kmod.mk, line 311: if-less endif /usr/src/sys/modules/ata/atapci/../../../conf/kmod.mk, line 311: Need an operator /usr/src/sys/modules/ata/atapci/../../../conf/kmod.mk, line 313: Need an operator /usr/src/sys/modules/ata/atapci/../../../conf/kmod.mk, line 311: if-less endif /usr/src/sys/modules/ata/atapci/../../../conf/kmod.mk, line 311: Need an operator /usr/src/sys/modules/ata/atapci/../../../conf/kmod.mk, line 313: Need an operator /usr/src/sys/modules/ata/atapci/../../../conf/kmod.mk, line 325: Need an operator Makefile, line 9: 1 open conditional: Makefile, line 9: at line 315 (evaluated to true) make: fatal errors encountered -- cannot continue *** Error code 1 Stop in /usr/src/sys/modules/ata. *** Error code 1 Stop in /usr/src/sys/modules. *** Error code 1 Stop in /usr/obj/usr/src/sys/GENERIC. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. # And yes, if I do a 'make buildworld' beforehand, I get the same error. Does this error happen all the time or only with ATA mkIII? Check /etc/stable-supfile to make sure you're getting RELENG_5_4 (tag=RELENG_5_4 and no date=). Also, do any of the hunks fail when patching? An easy way to find out is by checking the patch before applying (this is a good habit anyway): $ cd /usr/src $ patch -C ~/ata-mk3n.diff-releng5 21 | grep Hunk If they all say succeeded then the patch should apply correctly. If this doesn't generate any leads, try make -DALWAYS_CHECK_MAKE buildworld before building the kernel. I'm not sure but this could be an out-of-date make. Hope that helps. - -- Jonathan Noack | [EMAIL PROTECTED] | OpenPGP: 0x991D8195 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (MingW32) iD8DBQFCcTB9UFz01pkdgZURAhzxAKCUrw4pd3FbN+RNsEnZNsx/nShjlQCfUcF2 wQ1CdxV0knP3z256NXyFIQU= =sGNH -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: UPDATE: ATA mkIII official patches for releng_5
Thus spake Jonathan Noack ([EMAIL PROTECTED]) [28/04/05 14:53]: : Does this error happen all the time or only with ATA mkIII? Only with ATA mkIII. I'm running a system that I rebuilt this morning without issue. : Check /etc/stable-supfile to make sure you're getting RELENG_5_4 : (tag=RELENG_5_4 and no date=). Also, do any of the hunks fail when : patching? An easy way to find out is by checking the patch before : applying (this is a good habit anyway): I'm definitely running RELENG_5_4 (I've also tried with RELENG_5), and none of the hunks fail: % cd /usr/src % find . -type f -name \*.rej % : If they all say succeeded then the patch should apply correctly. If : this doesn't generate any leads, try make -DALWAYS_CHECK_MAKE : buildworld before building the kernel. I'm not sure but this could be : an out-of-date make. Not likely if the system I'm running was built this morning. Though I admit, it does /feel/ like a make error. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB changes.
Julian Elischer wrote: +++ Currently, I find my P4 hanging just after discovering the parallel port and mounting disk; in other words, just here: but -only- when my Logitech USB mouse is plugged in. Now, if I unplug it and hit reset (not Ctrl-Alt-Del; the keyboard is frozen) the system boots, and I can obtain X w/ a functional mouse. Yesterday, of course, prior to the USB change the system did not hang. try plugging the mouse in again before X starts. I saw this problem in testing ad THOUGHT I had checked in the fix.. Can you confirm that usb.c ends with: SYSINIT(usb_cold_explore, SI_SUB_INT_CONFIG_HOOKS, SI_ORDER_FIRST, usb_cold_explore, NULL); I noticed that some code was changed in between my discovery of the hanging and my attempt to fix it: Apr 27 21:15 subr_bus.c but this change, and the subsequent world update, did not solve the issue of the hanging mouse. the changes that you are refering to include some to defer probing of the USB 1.1 busses untill after the USB2.0 busses have been configured. They should probe for the devices at around the same time that the scsi devices probe. I'll see if I can duplicate yuor problem.. I tested with several USB 1.1 devices but a mounse was not amongst them. I tried to duplicate this but failed.. my mose was found just fine.. can you boot with the -v option? i.e. boot -v fromt eh loader prompt. See, I know I've only myself to blame for missing the announcement and/or starting an upgrade in an interstice between stability and apparent instability. But still...test first, deploy later, perhaps? Kernel bits, had them for a couple of years now: device uhci device ohci device ehci device usb device ugen device ums device uscanner With my luck, it's probably not the mouse after all. what about if you don't have the ums driver loaded? I assume it works right if you remove the mouse before booting and reinsert it after the kernel has booted? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB changes.
On Thu, Apr 28, 2005 at 11:23:14AM -0700, Julian Elischer wrote:
+++
Currently, I find my P4 hanging just after discovering the parallel
port and mounting disk; in other words, just here:
ppc0: parallel port not found.
ad0: 28629MB ST330620A [58168/16/63] at ata0-master UDMA100
but -only- when my Logitech USB mouse is plugged in. Now, if I
unplug it and hit reset (not Ctrl-Alt-Del; the keyboard is frozen) the
system boots, and I can obtain X w/ a functional mouse. Yesterday, of
course, prior to the USB change the system did not hang.
I saw this problem in testing ad THOUGHT I had checked in the fix..
Can you confirm that usb.c ends with:
SYSINIT(usb_cold_explore, SI_SUB_INT_CONFIG_HOOKS, SI_ORDER_FIRST,
usb_cold_explore, NULL);
Hmmm...
/usr/src/lib/libusbhid/
Nope..
Aha...maybe this is it:
/usr/src/usr.sbin/usbd/
ll /usr/src/usr.sbin/usbd/
2734320 -rw-r--r--1 root wheel169 Apr 25 2001 Makefile
2738254 -rw-r--r--1 root wheel 4460 Jun 22 2003 usbd.8
2736938 -rw-r--r--1 root wheel 30079 Nov 29 2003 usbd.c
2737339 -rw-r--r--1 root wheel 5046 Aug 27 2004 usbd.conf.5
Is that the one?
Here is a part of 'tail -25' on the file, showing the bottom:
/* check the event queue */
if (handle_events (FD_ISSET(fd, r) || error == 0))
{
if (verbose = 2)
printf(%s: processing event queue
%son %s\n,
__progname,
(error? :due to timeout ),
USBDEV);
process_event_queue(fd);
}
}
}
So no, this file doesn't end in what you ask; I can't see anywhere
else it might live; is there some other usbd.c you need?
I noticed that some code was changed in between my discovery of the
hanging and my attempt to fix it:
Apr 27 21:15 subr_bus.c
but this change, and the subsequent world update, did not solve the
issue of the hanging mouse.
the changes that you are refering to include some to defer probing of the
USB 1.1 busses untill after the USB2.0 busses have been configured.
Ah...okay; well, I was in the dark anyway, may as well whistle.
I'll see if I can duplicate yuor problem.. I tested with several USB 1.1
devices but a mounse was not amongst them.
Okay; it may be a one off, relative to me only, as I've seen no other
indications of issues. I am behind on my list reading, though.
I assume it works right if you remove the mouse before booting and reinsert
it after the kernel has booted?
Yes; once I have a console, the mouse is detected:
ums0: Logitech USB Receiver, rev 1.10/23.02, addr 2, iclass 3/1
ums0: 7 buttons and Z dir.
Then, it works in X just fine; I forgot to test it on the console.
--
I don't care what you think. This is not a stylishly insouciant stroll
out of the jungle, here. It's more like we've fallen out of our trees
and rolled, butt-naked before the entire galaxy, downhill. That, and
we seem to have a teensy problem lifting ourselves off the ground.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: UPDATE: ATA mkIII official patches for releng_5
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 4/28/2005 1:54 PM, Damian Gerow wrote: Thus spake Jonathan Noack ([EMAIL PROTECTED]) [28/04/05 14:53]: : Does this error happen all the time or only with ATA mkIII? Only with ATA mkIII. I'm running a system that I rebuilt this morning without issue. : Check /etc/stable-supfile to make sure you're getting RELENG_5_4 : (tag=RELENG_5_4 and no date=). Also, do any of the hunks fail when : patching? An easy way to find out is by checking the patch before : applying (this is a good habit anyway): I'm definitely running RELENG_5_4 (I've also tried with RELENG_5), and none of the hunks fail: % cd /usr/src % find . -type f -name \*.rej % : If they all say succeeded then the patch should apply correctly. If : this doesn't generate any leads, try make -DALWAYS_CHECK_MAKE : buildworld before building the kernel. I'm not sure but this could be : an out-of-date make. Not likely if the system I'm running was built this morning. Though I admit, it does /feel/ like a make error. Have you ever removed /usr/obj? If not, give it a little rm -rf /usr/obj action and try again. Otherwise, I'm running low on ideas. We may need to bring in a make guru... - -- Jonathan Noack | [EMAIL PROTECTED] | OpenPGP: 0x991D8195 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (MingW32) iD8DBQFCcTcJUFz01pkdgZURAnWuAKDJBmH2kUI2/AvvNauh+y3njqen8gCfdjds DHiTsPAbBAhIujpH+zwjJ88= =cBs5 -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: fsck_ufs: cannot increase directory list
Eric Anderson [EMAIL PROTECTED] wrote: I rebooted my server, and fsck'ed the disks, and here's what I get: # fsck -y /vol1 ** /dev/da0s1d ** Last Mounted on /vol1 ** Phase 1 - Check Blocks and Sizes fsck_ufs: cannot increase directory list That error message is printed if a memory allocation fails. (It's the memory that fsck uses for caching the inodes of directories.) # df -i Filesystem 1K-blocksUsed Avail Capacity iused ifree %iused Mounted on /dev/da0s1d1891668564 1643042028 9729305294% 32927755 211542003 13% /vol1 What's wrong? It lets me mount it rw and ro, but I'm afraid data is going to get corrupt. Well, you have a 2 Tbyte filesystem with nearly 250 million inodes. That's really a lot, and fsck will need a lot of memory (and probably run for a long time). First you should check if you hit a (soft or hard) resource limit with the ulimit command. See sh(1) for details on the ulimit usage. If you ran fsck in single user mode, you might have to enable swapping beforehand (swapon -a) if your physical RAM is not sufficient. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co KG, Oettingenstr. 2, 80538 München Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. I suggested holding a Python Object Oriented Programming Seminar, but the acronym was unpopular. -- Joseph Strout ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB changes.
Joe Altman wrote:
On Thu, Apr 28, 2005 at 11:23:14AM -0700, Julian Elischer wrote:
+++
Currently, I find my P4 hanging just after discovering the parallel
port and mounting disk; in other words, just here:
ppc0: parallel port not found.
ad0: 28629MB ST330620A [58168/16/63] at ata0-master UDMA100
but -only- when my Logitech USB mouse is plugged in. Now, if I
unplug it and hit reset (not Ctrl-Alt-Del; the keyboard is frozen) the
system boots, and I can obtain X w/ a functional mouse. Yesterday, of
course, prior to the USB change the system did not hang.
I saw this problem in testing ad THOUGHT I had checked in the fix..
Can you confirm that usb.c ends with:
SYSINIT(usb_cold_explore, SI_SUB_INT_CONFIG_HOOKS, SI_ORDER_FIRST,
usb_cold_explore, NULL);
Hmmm...
/usr/src/lib/libusbhid/
Nope..
/usr/sr/sys/dev/usb/usb.c
Aha...maybe this is it:
/usr/src/usr.sbin/usbd/
nope
ll /usr/src/usr.sbin/usbd/
2734320 -rw-r--r--1 root wheel169 Apr 25 2001 Makefile
2738254 -rw-r--r--1 root wheel 4460 Jun 22 2003 usbd.8
2736938 -rw-r--r--1 root wheel 30079 Nov 29 2003 usbd.c
2737339 -rw-r--r--1 root wheel 5046 Aug 27 2004 usbd.conf.5
Is that the one?
Here is a part of 'tail -25' on the file, showing the bottom:
/* check the event queue */
if (handle_events (FD_ISSET(fd, r) || error == 0))
{
if (verbose = 2)
printf(%s: processing event queue
%son %s\n,
__progname,
(error? :due to timeout ),
USBDEV);
process_event_queue(fd);
}
}
}
So no, this file doesn't end in what you ask; I can't see anywhere
else it might live; is there some other usbd.c you need?
I noticed that some code was changed in between my discovery of the
hanging and my attempt to fix it:
Apr 27 21:15 subr_bus.c
but this change, and the subsequent world update, did not solve the
issue of the hanging mouse.
the changes that you are refering to include some to defer probing of the
USB 1.1 busses untill after the USB2.0 busses have been configured.
Ah...okay; well, I was in the dark anyway, may as well whistle.
theoretically it may be that the usb code doesn't like being run at that
time..
I'll try duplicate your setup more closely.
is it a uhci or ohci controller?
I just realised I did most of my testing with ohci..
will hunt down a uhci machine to test with.
I'll see if I can duplicate yuor problem.. I tested with several USB 1.1
devices but a mounse was not amongst them.
Okay; it may be a one off, relative to me only, as I've seen no other
indications of issues. I am behind on my list reading, though.
I assume it works right if you remove the mouse before booting and reinsert
it after the kernel has booted?
Yes; once I have a console, the mouse is detected:
ums0: Logitech USB Receiver, rev 1.10/23.02, addr 2, iclass 3/1
ums0: 7 buttons and Z dir.
Then, it works in X just fine; I forgot to test it on the console.
shouldn't matter..
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB changes.
Joe Altman wrote: On Thu, Apr 28, 2005 at 11:23:14AM -0700, Julian Elischer wrote: [...] I assume it works right if you remove the mouse before booting and reinsert it after the kernel has booted? Yes; once I have a console, the mouse is detected: ums0: Logitech USB Receiver, rev 1.10/23.02, addr 2, iclass 3/1 ums0: 7 buttons and Z dir. Then, it works in X just fine; I forgot to test it on the console. seems to work for me with uhci too.. can you see if changing the BIOS usb optiosn makes a difference? [...] uhci0: UHCI (generic) USB controller port 0xe800-0xe81f irq 5 at device 29.0 o n pci0 usb0: UHCI (generic) USB controller on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: UHCI (generic) USB controller port 0xec00-0xec1f irq 9 at device 29.1 o n pci0 usb1: UHCI (generic) USB controller on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered pci0: unknown card (vendor=0x8086, dev=0x25ab) at 29.4 pci0: unknown card (vendor=0x8086, dev=0x25ac) at 29.5 ehci0: EHCI (generic) USB 2.0 controller mem 0xfe7ffc00-0xfe7f irq 7 at de vice 29.7 on pci0 usb2: EHCI version 1.0 usb2: companion controllers, 2 ports each: usb0 usb1 usb2: EHCI (generic) USB 2.0 controller on ehci0 usb2: USB revision 2.0 uhub2: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub2: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub2: single transaction translator uhub2: 4 ports with 4 removable, self powered [...] psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model IntelliMouse, device ID 3 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x100 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A, console sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A ppc0: parallel port not found. DUMMYNET initialized (011031) IP packet filtering initialized, divert enabled, rule-based forwarding enabled, default to accept, logging disabled IPsec: Initialized Security Association Processing. ad0: 114473MB ST3120026A [232581/16/63] at ata0-master UDMA100 ums0: Microsoft Microsoft 3-Button Mouse with IntelliEye(TM), rev 1.10/3.00, add r 2, iclass 3/1 ums0: 3 buttons and Z dir. Mounting root from ufs:/dev/ad0s1a ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB changes.
On Thu, Apr 28, 2005 at 12:55:31PM -0700, Julian Elischer wrote: Can you confirm that usb.c ends with: SYSINIT(usb_cold_explore, SI_SUB_INT_CONFIG_HOOKS, SI_ORDER_FIRST, usb_cold_explore, NULL); /usr/sr/sys/dev/usb/usb.c Aha...maybe this is it: /usr/src/usr.sbin/usbd/ nope ll /usr/src/usr.sbin/usbd/ 2734320 -rw-r--r--1 root wheel169 Apr 25 2001 Makefile 2738254 -rw-r--r--1 root wheel 4460 Jun 22 2003 usbd.8 2736938 -rw-r--r--1 root wheel 30079 Nov 29 2003 usbd.c 2737339 -rw-r--r--1 root wheel 5046 Aug 27 2004 usbd.conf.5 Is that the one? Where does the file that you need live? theoretically it may be that the usb code doesn't like being run at that time.. I'll try duplicate your setup more closely. is it a uhci or ohci controller? From dmesg: uhci0: Intel 82801EB (ICH5) USB controller USB-A port 0xbc00-0xbc1f irq 5 at device 29.0 on pci0 usb0: Intel 82801EB (ICH5) USB controller USB-A on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: Intel 82801EB (ICH5) USB controller USB-B port 0xb000-0xb01f irq 10 at device 29.1 on pci0 usb1: Intel 82801EB (ICH5) USB controller USB-B on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: Intel 82801EB (ICH5) USB controller USB-C port 0xb400-0xb41f irq 11 at device 29.2 on pci0 usb2: Intel 82801EB (ICH5) USB controller USB-C on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered uhci3: Intel 82801EB (ICH5) USB controller USB-D port 0xb800-0xb81f irq 5 at device 29.3 on pci0 usb3: Intel 82801EB (ICH5) USB controller USB-D on uhci3 usb3: USB revision 1.0 uhub3: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub3: 2 ports with 2 removable, self powered ehci0: EHCI (generic) USB 2.0 controller mem 0xfc00-0xfc0003ff irq 3 at device 29.7 on pci0 usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: EHCI (generic) USB 2.0 controller on ehci0 usb4: USB revision 2.0 uhub4: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub4: single transaction translator uhub4: 8 ports with 8 removable, self powered So it's uhci and ehci. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [SOLVED] VIA M1000 mini-itx system installation woes - WRITE_DMA error
This solution worked like a charm! Thanks Arjan! One note: use set ... syntax in the interactive loader prompt (6), and use hw.ata.ata_dma=0 *without* set in /boot/loader.conf Interestingly, setting the drive in the BIOS to PIO4 mode had no effect. Now if I can just get carrier on my vr0 interface, I won't have to return this system! Woody From: Arjan Van Leeuwen [EMAIL PROTECTED] Reply-To: Arjan Van Leeuwen [EMAIL PROTECTED] To: W C [EMAIL PROTECTED] CC: freebsd-stable@freebsd.org Subject: Re: VIA M1000 mini-itx system installation woes - WRITE_DMA error -cabling? Date: Wed, 27 Apr 2005 10:11:16 +0200 On 4/26/05, W C [EMAIL PROTECTED] wrote: Hi all, I am attempting to install 5.3-R from cd (iso image download) and sysinstall is failing to write the chosen (Auto Layout) filesystem to disk, the Toshiba 80G on the primary ide channel as master. The error on vty1 is (from memory) ad0: WRITE_DMA, error=84. The drive is detected by BIOS as a UDMA100 device. There is nothing else on this IDE channel, and only a cd drive on the other IDE slot. A search of -questions reveals this error is a UDMA mismatch, possible caused by 80-pin cabling, and fixable with atacontrol ad0 udma33 pio bla bla bla. However, I do not yet have a running system to run atacontrol from, as I am installing. I have rooted around in the bios for an option to force the drive to UDMA33 speed, to no avail. Does anyone know how I can work around this problem and install FreeBSD to this neat little system? Do I have bad cabling, a bad drive, or ??? Yes, I had the same problem. If this is a 2.5 drive, it probably doesn't have a 80-pins cable. Force PIO mode for the install by entering at the boot prompt (option 6 in the boot loader menu): set hw.ata.ata_dma=0 boot After you've installed the system, insert that line into /boot/loader.conf, and load up atacontrol mode 0 udma33 udma33 as early as possible during the boot (try using /etc/rc.early, for example) to get it up to speed again. Arjan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] _ On the road to retirement? Check out MSN Life Events for advice on how to get there! http://lifeevents.msn.com/category.aspx?cid=Retirement ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB changes.
Joe Altman wrote: On Thu, Apr 28, 2005 at 12:55:31PM -0700, Julian Elischer wrote: Can you confirm that usb.c ends with: SYSINIT(usb_cold_explore, SI_SUB_INT_CONFIG_HOOKS, SI_ORDER_FIRST, usb_cold_explore, NULL); /usr/src/sys/dev/usb/usb.c ^^^ Where does the file that you need live? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB changes.
On Thu, Apr 28, 2005 at 01:23:25PM -0700, Julian Elischer wrote:
Joe Altman wrote:
On Thu, Apr 28, 2005 at 12:55:31PM -0700, Julian Elischer wrote:
Can you confirm that usb.c ends with:
SYSINIT(usb_cold_explore, SI_SUB_INT_CONFIG_HOOKS, SI_ORDER_FIRST,
usb_cold_explore, NULL);
/usr/src/sys/dev/usb/usb.c
^^^
Oh; sorry...I must have gone cross-eyed.
Here is the tail of the file, with timestamp:
Apr 27 00:07 /usr/src/sys/dev/usb/usb.c
/* Explore USB busses at the end of device configuration. */
Static void
usb_cold_explore(void *arg)
{
struct usb_softc *sc;
KASSERT(cold || TAILQ_EMPTY(usb_coldexplist),
(usb_cold_explore: busses to explore when !cold));
while (!TAILQ_EMPTY(usb_coldexplist)) {
sc = TAILQ_FIRST(usb_coldexplist);
TAILQ_REMOVE(usb_coldexplist, sc, sc_coldexplist);
sc-sc_bus-use_polling++;
sc-sc_port.device-hub-explore(sc-sc_bus-root_hub);
sc-sc_bus-use_polling--;
}
}
DRIVER_MODULE(usb, ohci, usb_driver, usb_devclass, 0, 0);
DRIVER_MODULE(usb, uhci, usb_driver, usb_devclass, 0, 0);
DRIVER_MODULE(usb, ehci, usb_driver, usb_devclass, 0, 0);
SYSINIT(usb_cold_explore, SI_SUB_INT_CONFIG_HOOKS, SI_ORDER_FIRST,
usb_cold_explore, NULL);
#endif
--
I don't care what you think. This is not a stylishly insouciant stroll
out of the jungle, here. It's more like we've fallen out of our trees
and rolled, butt-naked before the entire galaxy, downhill. That, and
we seem to have a teensy problem lifting ourselves off the ground.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
unexpected panic in idle process (RELENG_5 2005/04/25UTC)
I've been running RELENG_5 -D2005/04/25UTC on a CF-based system (PC Engines WRAP.1C v1.03; 640 KB Base Memory; 130048 KB Extended Memory) CF: 01F0 Master 848A Hitachi XX.V.3.4.0.0 Phys C/H/S 978/8/32 Log C/H/S 978/8/32 ... CPU: Geode(TM) Integrated Processor by National Semi (266.64-MHz 586-class CPU) Origin = Geode by NSC Id = 0x540 Stepping = 0 Features=0x808131FPU,TSC,MSR,CX8,CMOV,MMX ... after a few hours (mainly idle and ntpd), I was surprised to note on the console: Fatal trap 9: general protection fault while in kernel mode instruction pointer = 0x8:0xc05e8ca2 stack pointer = 0x10:0xc7499d10 frame pointer = 0x10:0xc7499d10 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 = 11 (idle) [thread pid 11 tid 13 ] Stopped at cpu_idle_default+0x5: leave I've got: db where Tracing pid 11 tid 13 td 0xc0ac6480 cpu_idle_default(c0ac5c5c,c7499d34,c049e404,0,c7499d48) at cpu_idle_default+0x5 idle_proc(0,c7499d48,0,c049e628,0) at idle_proc+0x11 fork_exit(c049e628,0,c7499d48) at fork_exit+0x6f fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xc7499d7c, ebp = 0 --- db ps pid proc uid ppid pgrp flag stat wmesgwchan cmd 931 c109e000 1001 930 931 0004002 [SLPQ ttyin 0xc0b65a10][SLP] bash 930 c109e1c4 1001 928 928 100 [SLPQ select 0xc0674e24][SLP] sshd 928 c109ea980 831 928 100 [SLPQ sbwait 0xc0f49974][SLP] sshd 927 c10a21c40 1 927 0004002 [SLPQ ttyin 0xc0abea10][SLP] getty 853 c0b507100 1 853 000 [SLPQ nanslp 0xc067182c][SLP] cron 841 c0bf7710 25 1 841 100 [SLPQ pause 0xc0bf7748][SLP] sendmail 837 c0b508d40 1 837 100 [SLPQ select 0xc0674e24][SLP] sendmail 831 c0b501c40 1 831 100 [SLPQ select 0xc0674e24][SLP] sshd 818 c0b503880 1 818 000 [SLPQ select 0xc0674e24][SLP] ntpd 710 c0bf70000 1 710 000 [SLPQ select 0xc0674e24][SLP] syslogd 101 c0b50c5c0 0 0 204 [SLPQ mdwait 0xc0bf8d00][SLP] md2 91 c0bf754c0 0 0 204 [SLPQ mdwait 0xc0c23a00][SLP] md1 71 c0bf73880 0 0 204 [SLPQ mdwait 0xc0c23600][SLP] md0 46 c0afaa980 0 0 204 [SLPQ - 0xc74dbd0c][SLP] schedcpu 45 c0afac5c0 0 0 204 [SLPQ - 0xc067db2c][SLP] nfsiod 3 44 c0afae200 0 0 204 [SLPQ - 0xc067db28][SLP] nfsiod 2 43 c0b4c0000 0 0 204 [SLPQ - 0xc067db24][SLP] nfsiod 1 42 c0b4c1c40 0 0 204 [SLPQ - 0xc067db20][SLP] nfsiod 0 41 c0b4c3880 0 0 204 [SLPQ syncer 0xc06715ac][SLP] syncer 40 c0b4c54c0 0 0 204 [SLPQ vlruwt 0xc0b4c54c][SLP] vnlru 39 c0b4c7100 0 0 204 [SLPQ psleep 0xc06753ec][SLP] bufdaemon 38 c0b4c8d40 0 0 204 [SLPQ pollid 0xc066f184][SLP] idlepoll 37 c0b4ca980 0 0 20c [SLPQ pgzero 0xc0684554][SLP] pagezero 9 c0b4cc5c0 0 0 204 [SLPQ psleep 0xc0684564][SLP] pagedaemon 36 c0b4ce200 0 0 204 [IWAIT] swi0: sio 8 c0b50 0 0 204 [SLPQ - 0xc0b34d80][SLP] thread taskq 35 c0ae854c0 0 0 204 [IWAIT] swi6:+ 7 c0ae87100 0 0 204 [SLPQ - 0xc0b34e40][SLP] kqueue taskq 34 c0ae88d40 0 0 204 [IWAIT] swi3: cambio 33 c0ae8a980 0 0 204 [IWAIT] swi2: camnet 32 c0ae8c5c0 0 0 204 [IWAIT] swi6: task queue 31 c0ae8e200 0 0 204 [IWAIT] swi6:+ 30 c0afa0000 0 0 204 [SLPQ - 0xc06676c0][SLP] yarrow 6 c0afa1c40 0 0 204 [SLPQ crypto_ret_wait 0xc0683584][SLP] crypto returns 5 c0afa3880 0 0 204 [SLPQ crypto_wait 0xc0683544][SLP] crypto 4 c0afa54c0 0 0 204 [SLPQ - 0xc066ba68][SLP] g_down 3 c0afa7100 0 0 204 [SLPQ - 0xc066ba64][SLP] g_up 2 c0afa8d40 0 0 204 [SLPQ - 0xc066ba5c][SLP] g_event 29 c0acc1c40 0 0 204 [IWAIT] swi1: net 28 c0acc3880 0 0 204 [IWAIT] swi4: vm 27 c0acc54c0 0 0 20c [RUNQ] swi5: clock sio 26 c0acc7100 0 0 204 [IWAIT] irq15: ata1 25 c0acc8d40 0 0 204 [IWAIT] irq14: ata0 24 c0acca980 0 0 204 [IWAIT] irq13: 23 c0accc5c0 0 0 204 [IWAIT] irq12: hifn0 22 c0acce200 0 0 204 [IWAIT] irq11: sis2 21 c0ae80000 0 0 204 [IWAIT] irq10: sis0 20 c0ae81c40 0 0 204 [IWAIT] irq9: sis1 19 c0ae83880 0 0 204 [IWAIT] irq8: rtc 18 c0ac50000 0 0 204 [IWAIT] irq7: 17 c0ac51c40 0 0 204 [IWAIT] irq6: 16 c0ac53880 0 0 204 [IWAIT] irq5:
Re: USB changes.
Since I can't make this happen here, I'm going to need help..
Joe Altman wrote:
Apr 27 00:07 /usr/src/sys/dev/usb/usb.c
/* Explore USB busses at the end of device configuration. */
Static void
usb_cold_explore(void *arg)
{
struct usb_softc *sc;
can you add this line here:
printf(HEY WE GOT HERE!\n);
KASSERT(cold || TAILQ_EMPTY(usb_coldexplist),
(usb_cold_explore: busses to explore when !cold));
while (!TAILQ_EMPTY(usb_coldexplist)) {
sc = TAILQ_FIRST(usb_coldexplist);
TAILQ_REMOVE(usb_coldexplist, sc, sc_coldexplist);
and:
printf(probing a USB 1.1 bus.\n);
sc-sc_bus-use_polling++;
sc-sc_port.device-hub-explore(sc-sc_bus-root_hub);
sc-sc_bus-use_polling--;
}
}
DRIVER_MODULE(usb, ohci, usb_driver, usb_devclass, 0, 0);
DRIVER_MODULE(usb, uhci, usb_driver, usb_devclass, 0, 0);
DRIVER_MODULE(usb, ehci, usb_driver, usb_devclass, 0, 0);
SYSINIT(usb_cold_explore, SI_SUB_INT_CONFIG_HOOKS, SI_ORDER_FIRST,
usb_cold_explore, NULL);
#endif
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB changes.
On Thu, Apr 28, 2005 at 01:40:50PM -0700, Julian Elischer wrote: Since I can't make this happen here, I'm going to need help.. What do you need? Relatively speaking, I'm sort of a newbie at the more complex aspects of bugs, and this strikes me as somewhat complex. But if you are willing to tell me what you need, and how to proceed or what to read to help you, I'll do what I can. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB changes.
Joe Altman wrote: On Thu, Apr 28, 2005 at 01:40:50PM -0700, Julian Elischer wrote: Since I can't make this happen here, I'm going to need help.. What do you need? Relatively speaking, I'm sort of a newbie at the more complex aspects of bugs, and this strikes me as somewhat complex. But if you are willing to tell me what you need, and how to proceed or what to read to help you, I'll do what I can. I asked you to add 2 lines to that file and try again. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
5.4 Stable
when will go to leave the 5,4 stable? The calendar speaks that already it must have left in day 26/04. Sylvio César. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.4 Stable
On Thu, April 28, 2005 4:53 pm, Sylvio Cesar said: when will go to leave the 5,4 stable? The calendar speaks that already it must have left in day 26/04. Basically whenever the developers and release team feel that its ready. The posted timeline is more of a rough guide, and not strict rule. But my guess it will be out within a week or so. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
