From bugmaster at FreeBSD.org Mon May 4 11:07:47 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon May 4 11:08:27 2009 Subject: Current problem reports assigned to freebsd-firewire@FreeBSD.org Message-ID: <200905041107.n44B7jLe098520@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- p kern/125673 firewire [firewire] [panic] FreeBSD7 panics when kldunloading f o kern/122951 firewire [firewire] video-transfer via fwcontrol triggers a pan o kern/118093 firewire [firewire] firewire bus reset hogs CPU, causing data t p kern/114646 firewire [firewire] [patch] firewire fails after suspend/resume o kern/113785 firewire [firewire] dropouts when playing DV on firewire o kern/97208 firewire [firewire] System hangs / locks up when a firewire dis o kern/74238 firewire [firewire] fw_rcv: unknown response; firewire ad-hoc w 7 problems total. From sean.bruno at dsl-only.net Mon May 4 22:22:03 2009 From: sean.bruno at dsl-only.net (Sean Bruno) Date: Mon May 4 22:22:09 2009 Subject: BSDCan BOF Plugfest Message-ID: <1241475705.7488.2.camel@localhost.localdomain> Just a reminder, I'll be lounging around BSDCan for most of the week(starting Tuesday night late) hoping to test your laptop, external hard drive or camera with FreeBSD Current. If you have PCI boards that you would like to have tested, I will have a PC available to test with as well. See you all there! Sean Bruno From sean.bruno at dsl-only.net Mon May 4 22:39:09 2009 From: sean.bruno at dsl-only.net (Sean Bruno) Date: Mon May 4 22:39:16 2009 Subject: BSDCan BOF Plugfest In-Reply-To: <1241475705.7488.2.camel@localhost.localdomain> References: <1241475705.7488.2.camel@localhost.localdomain> Message-ID: <1241476747.7488.3.camel@localhost.localdomain> On Mon, 2009-05-04 at 15:21 -0700, Sean Bruno wrote: > Just a reminder, I'll be lounging around BSDCan for most of the > week(starting Tuesday night late) hoping to test your laptop, external > hard drive or camera with FreeBSD Current. > > If you have PCI boards that you would like to have tested, I will have a > PC available to test with as well. See you all there! > > Sean Bruno > Huh ... I guess I should specify that I'm interested in Firewire products. :) Sean From freebsd at sopwith.solgatos.com Mon May 11 06:59:53 2009 From: freebsd at sopwith.solgatos.com (Dieter) Date: Mon May 11 06:59:59 2009 Subject: kern/118093: [firewire] firewire bus reset hogs CPU, causing data to be lost In-Reply-To: Your message of "Fri, 06 Mar 2009 16:00:08 GMT." <200903061600.n26G082b030204@freefall.freebsd.org> Message-ID: <200905101820.SAA05694@sopwith.solgatos.com> > > > This looks like it may be some bad > > > interaction between the firewire stack and using a serial > > > console. To submitter: It may be worth while switching to > > > uart(4) rather than sio(4) for your serial ports and seeing > > > if that makes any difference (as I don't think uart(4) uses > > > the Giant lock). > > Looks to me like commenting out sio doesn't work so well on my box. > > Is that the wrong way to switch from sio to uart? > > Is there something else I need to change instead, or in addition? > > You'll also need to add the uart hints to your device.hints file, if you > haven't already, and update /etc/ttys. > > hint.uart.0.at="isa" > hint.uart.0.port="0x3F8" > hint.uart.0.flags="0x10" > hint.uart.0.irq="4" > > /etc/ttys: you may find you need to change "ttyd0" to "ttyu0". > > Gavin Thanks, with those changes it works with uart now. The bad news is that switching from sio to uart didn't fix the CPU hogging problem. From freebsd at sopwith.solgatos.com Mon May 11 07:00:15 2009 From: freebsd at sopwith.solgatos.com (Dieter) Date: Mon May 11 07:00:24 2009 Subject: kern/118093: [firewire] firewire bus reset hogs CPU, causing data to be lost Message-ID: <200905110700.n4B70EGT010504@freefall.freebsd.org> The following reply was made to PR kern/118093; it has been noted by GNATS. From: Dieter To: Gavin Atkinson Cc: freebsd-firewire@freebsd.org, bug-followup@freebsd.org Subject: Re: kern/118093: [firewire] firewire bus reset hogs CPU, causing data to be lost Date: Sun, 10 May 2009 11:20:29 +0100 > > > This looks like it may be some bad > > > interaction between the firewire stack and using a serial > > > console. To submitter: It may be worth while switching to > > > uart(4) rather than sio(4) for your serial ports and seeing > > > if that makes any difference (as I don't think uart(4) uses > > > the Giant lock). > > Looks to me like commenting out sio doesn't work so well on my box. > > Is that the wrong way to switch from sio to uart? > > Is there something else I need to change instead, or in addition? > > You'll also need to add the uart hints to your device.hints file, if you > haven't already, and update /etc/ttys. > > hint.uart.0.at="isa" > hint.uart.0.port="0x3F8" > hint.uart.0.flags="0x10" > hint.uart.0.irq="4" > > /etc/ttys: you may find you need to change "ttyd0" to "ttyu0". > > Gavin Thanks, with those changes it works with uart now. The bad news is that switching from sio to uart didn't fix the CPU hogging problem. From bugmaster at FreeBSD.org Mon May 11 11:06:54 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon May 11 11:07:50 2009 Subject: Current problem reports assigned to freebsd-firewire@FreeBSD.org Message-ID: <200905111106.n4BB6rmw085927@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- p kern/125673 firewire [firewire] [panic] FreeBSD7 panics when kldunloading f o kern/122951 firewire [firewire] video-transfer via fwcontrol triggers a pan o kern/118093 firewire [firewire] firewire bus reset hogs CPU, causing data t p kern/114646 firewire [firewire] [patch] firewire fails after suspend/resume o kern/113785 firewire [firewire] dropouts when playing DV on firewire o kern/97208 firewire [firewire] System hangs / locks up when a firewire dis o kern/74238 firewire [firewire] fw_rcv: unknown response; firewire ad-hoc w 7 problems total. From jkim at FreeBSD.org Mon May 11 19:29:25 2009 From: jkim at FreeBSD.org (Jung-uk Kim) Date: Mon May 11 19:29:37 2009 Subject: [Fwd: Re: amd64 suspend/resume broken on current] In-Reply-To: <4A058B5C.3010707@FreeBSD.org> References: <4A058B5C.3010707@FreeBSD.org> Message-ID: <200905111529.12808.jkim@FreeBSD.org> [CC added] On Saturday 09 May 2009 09:55 am, Alexander Motin wrote: > -------- Original Message -------- > Subject: Re: amd64 suspend/resume broken on current > Date: Fri, 8 May 2009 21:52:45 +0200 > From: Guy Brand > Organization: Direction Informatique, Université de Strasbourg, > France To: Alexander Motin > References: > <4A021118.2030106@mavhome.dp.ua> <20090508111024.GK4922@unistra.fr> > <4A041DC2.90106@mavhome.dp.ua> <20090508144551.GA1599@unistra.fr> > <4A047925.6060301@mavhome.dp.ua> > > Guy Brand wrote: > > Alexander Motin wrote: > > > Done. No firewire issue of course, but a kernel panic on > > > resume. Bad karma since yesterday :-) > > > > Where is this panic happens now? > > Just after resuming: > > Fatal trap 12: page fault while in kernel mode > ... > current process = 1415 (acpiconf) > > The backtrace says: > > intr_execute_handlers() at intr_execute_handlers+0x21 > lapic_handle_intr() at lapic_handle_intr+0x37 > Xapic_isr1() at Xapic_isr1+0xa4 > > acpi_sleep_machdep() at acpi_sleep_machdep+0x3b2 > acpi_EnterSleepState() at acpi_EnterSleepState+0x3fe > acpi_AckSleepState() at acpi_AckSleepState+0x163 > devfs_ioctl() at devfs_ioctl_f+0x77 > kern_ioctl() at kern_ioctl+0xb0 > ioctl() at ioctl+0xfd > syscall() at syscal+0x246 > Xfast_syscall() at Xfast_syscall+0xd0 So, that means the interrupt handler is executed *before* device is completely resumed. In fact, the interrupts are not disabled for dcons(4), it seems: #if 0 /* Let dcons(4) be accessed */ /* Stop interrupt */ OWRITE(sc, FWOHCI_INTMASKCLR, OHCI_INT_EN | OHCI_INT_ERR | OHCI_INT_PHY_SID | OHCI_INT_PHY_INT | OHCI_INT_DMA_ATRQ | OHCI_INT_DMA_ATRS | OHCI_INT_DMA_PRRQ | OHCI_INT_DMA_PRRS | OHCI_INT_DMA_ARRQ | OHCI_INT_DMA_ARRS | OHCI_INT_PHY_BUS_R); /* FLUSH FIFO and reset Transmitter/Reciever */ OWRITE(sc, OHCI_HCCCTL, OHCI_HCC_RESET); #endif I guess firewire(4) should differentiate suspend and shutdown properly. Jung-uk Kim From jkim at FreeBSD.org Mon May 11 20:02:36 2009 From: jkim at FreeBSD.org (Jung-uk Kim) Date: Mon May 11 20:02:43 2009 Subject: [Fwd: Re: amd64 suspend/resume broken on current] In-Reply-To: <200905111529.12808.jkim@FreeBSD.org> References: <4A058B5C.3010707@FreeBSD.org> <200905111529.12808.jkim@FreeBSD.org> Message-ID: <200905111602.20462.jkim@FreeBSD.org> On Monday 11 May 2009 03:29 pm, Jung-uk Kim wrote: > [CC added] > > On Saturday 09 May 2009 09:55 am, Alexander Motin wrote: > > -------- Original Message -------- > > Subject: Re: amd64 suspend/resume broken on current > > Date: Fri, 8 May 2009 21:52:45 +0200 > > From: Guy Brand > > Organization: Direction Informatique, Université de Strasbourg, > > France To: Alexander Motin > > References: > > <4A021118.2030106@mavhome.dp.ua> > > <20090508111024.GK4922@unistra.fr> <4A041DC2.90106@mavhome.dp.ua> > > <20090508144551.GA1599@unistra.fr> > > <4A047925.6060301@mavhome.dp.ua> > > > > Guy Brand wrote: > > > Alexander Motin wrote: > > > > Done. No firewire issue of course, but a kernel panic on > > > > resume. Bad karma since yesterday :-) > > > > > > Where is this panic happens now? > > > > Just after resuming: > > > > Fatal trap 12: page fault while in kernel mode > > ... > > current process = 1415 (acpiconf) > > > > The backtrace says: > > > > intr_execute_handlers() at intr_execute_handlers+0x21 > > lapic_handle_intr() at lapic_handle_intr+0x37 > > Xapic_isr1() at Xapic_isr1+0xa4 > > > > acpi_sleep_machdep() at acpi_sleep_machdep+0x3b2 > > acpi_EnterSleepState() at acpi_EnterSleepState+0x3fe > > acpi_AckSleepState() at acpi_AckSleepState+0x163 > > devfs_ioctl() at devfs_ioctl_f+0x77 > > kern_ioctl() at kern_ioctl+0xb0 > > ioctl() at ioctl+0xfd > > syscall() at syscal+0x246 > > Xfast_syscall() at Xfast_syscall+0xd0 > > So, that means the interrupt handler is executed *before* device is > completely resumed. In fact, the interrupts are not disabled for > dcons(4), it seems: > > #if 0 /* Let dcons(4) be accessed */ > /* Stop interrupt */ > OWRITE(sc, FWOHCI_INTMASKCLR, > OHCI_INT_EN | OHCI_INT_ERR | > OHCI_INT_PHY_SID > > | OHCI_INT_PHY_INT > | OHCI_INT_DMA_ATRQ | OHCI_INT_DMA_ATRS > | OHCI_INT_DMA_PRRQ | OHCI_INT_DMA_PRRS > | OHCI_INT_DMA_ARRQ | OHCI_INT_DMA_ARRS > | OHCI_INT_PHY_BUS_R); > > /* FLUSH FIFO and reset Transmitter/Reciever */ > OWRITE(sc, OHCI_HCCCTL, OHCI_HCC_RESET); > #endif > > I guess firewire(4) should differentiate suspend and shutdown > properly. Can you try the attached patch? I may be wrong cause I am not a firewire guru, though. Thanks! Jung-uk Kim -------------- next part -------------- --- sys/dev/firewire/fwohci.c 13 Feb 2009 17:44:07 -0000 1.98 +++ sys/dev/firewire/fwohci.c 11 May 2009 19:46:24 -0000 @@ -1742,7 +1742,7 @@ } int -fwohci_stop(struct fwohci_softc *sc, device_t dev) +fwohci_stop(struct fwohci_softc *sc, device_t dev, int suspend) { u_int i; @@ -1759,9 +1759,10 @@ OWRITE(sc, OHCI_ITCTLCLR(i), OHCI_CNTL_DMA_RUN); } -#if 0 /* Let dcons(4) be accessed */ -/* Stop interrupt */ - OWRITE(sc, FWOHCI_INTMASKCLR, + /* Let dcons(4) be accessed if it is not suspending. */ + if (suspend) { + /* Stop interrupt */ + OWRITE(sc, FWOHCI_INTMASKCLR, OHCI_INT_EN | OHCI_INT_ERR | OHCI_INT_PHY_SID | OHCI_INT_PHY_INT | OHCI_INT_DMA_ATRQ | OHCI_INT_DMA_ATRS @@ -1769,9 +1770,9 @@ | OHCI_INT_DMA_ARRQ | OHCI_INT_DMA_ARRS | OHCI_INT_PHY_BUS_R); -/* FLUSH FIFO and reset Transmitter/Reciever */ - OWRITE(sc, OHCI_HCCCTL, OHCI_HCC_RESET); -#endif + /* FLUSH FIFO and reset Transmitter/Reciever */ + OWRITE(sc, OHCI_HCCCTL, OHCI_HCC_RESET); + } /* XXX Link down? Bus reset? */ return 0; --- sys/dev/firewire/fwohci_pci.c 9 Mar 2009 13:23:54 -0000 1.62 +++ sys/dev/firewire/fwohci_pci.c 11 May 2009 19:46:24 -0000 @@ -408,7 +408,7 @@ s = splfw(); if (sc->bsr) - fwohci_stop(sc, self); + fwohci_stop(sc, self, 0); bus_generic_detach(self); if (sc->fc.bdev) { @@ -462,7 +462,7 @@ err = bus_generic_suspend(dev); if (err) return err; - fwohci_stop(sc, dev); + fwohci_stop(sc, dev, 1); return 0; } @@ -482,7 +482,7 @@ fwohci_softc_t *sc = device_get_softc(dev); bus_generic_shutdown(dev); - fwohci_stop(sc, dev); + fwohci_stop(sc, dev, 0); return 0; } --- sys/dev/firewire/fwohcivar.h 3 Feb 2009 17:13:37 -0000 1.18 +++ sys/dev/firewire/fwohcivar.h 11 May 2009 19:46:24 -0000 @@ -83,4 +83,4 @@ void fwohci_reset (struct fwohci_softc *, device_t); int fwohci_detach (struct fwohci_softc *, device_t); int fwohci_resume (struct fwohci_softc *, device_t); -int fwohci_stop (struct fwohci_softc *, device_t dev); +int fwohci_stop (struct fwohci_softc *, device_t, int); From bugmaster at FreeBSD.org Mon May 18 11:06:51 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon May 18 11:07:53 2009 Subject: Current problem reports assigned to freebsd-firewire@FreeBSD.org Message-ID: <200905181106.n4IB6oHl075626@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- p kern/125673 firewire [firewire] [panic] FreeBSD7 panics when kldunloading f o kern/122951 firewire [firewire] video-transfer via fwcontrol triggers a pan o kern/118093 firewire [firewire] firewire bus reset hogs CPU, causing data t p kern/114646 firewire [firewire] [patch] firewire fails after suspend/resume o kern/113785 firewire [firewire] dropouts when playing DV on firewire o kern/97208 firewire [firewire] System hangs / locks up when a firewire dis o kern/74238 firewire [firewire] fw_rcv: unknown response; firewire ad-hoc w 7 problems total. From cwhiteh at onetel.com Wed May 20 19:04:23 2009 From: cwhiteh at onetel.com (Chris Whitehouse) Date: Wed May 20 19:04:30 2009 Subject: [Fwd: run_interrupt_driven_hooks: still waiting... for xpt_config] Message-ID: <4A14519C.7090205@onetel.com> Hi, I asked this question on questions@ but didn't get a reply. Since I seem to have narrowed the problem down to the sbp driver I am hoping this might be a good place to ask. [Please could you copy me on any reply as I am not subscribed to this list, thanks] I'm trying to install on a new motherboard ASUS M3N78-EM. While booting from CD I'm getting run_interrupts_driven_hooks: still waiting after 60 seconds for xpt_config This is repeated a few times then installation stops and the machine stops responding. I've tried various versions of FreeBSD, including 6.4R, 7.0R 7.2R and 8.0-CURRENT-200905-i386-disc1.iso, all i386. I've also tried SATA mode and AHCI mode for the SATA controller. I get panicks on 8.0-CURRENT and on 7.2R with a debug kernel. After some trial and error the problem seems to be device sbp in the kernel config file. Comment that out and rebuild kernel and it boots. Here's a backtrace from 7.2R using a GENERIC kernel (with sbp enabled) with debug options added. run_interrupt_driven_hooks: still waiting after 300 seconds for xpt_config panic: run_interrupt_driven_config_hooks: waited too long cpuid=0 KDB: enter: panic [thread pid 0 tid 0 ] stopped at kdb_enter_why+0x3a: movl $0,kdb_why db> bt Tracing pid 0 tid 0 td 0xc0cc1b40 kdb_enter_why(c0b87110,c0b87110,c0b89425,c1020d0c,0,...) at kdb_enter_why+0x3a panic(c0b89425,0,c0b893c0,71,ea60,...) at panic+0x136 run_interrupt_driven_config_hooks(0,101ec00,101ec00,101e000,1025000,...) at run_interrupt_driven_config_hooks+0x1b7 mi_startup() at mi_startup+0x96 begin()at begin+0x2c db> Here's a backtrace from 8.0-CURRENT panic: run_interrupt_driven_config_hooks: waited too long cpuid=0 KDB: enter: panic [thread pid 0 tid 100000 ] stopped at kdb_enter+0x3a: movl $0,kdb_why db> bt Tracing pid 0 tid 100000 td 0xc0d88fd0 kdb_enter(c0c3d8cf,c0c3d8cf,c0c3feac,c1820d08,0,...) at kdb_enter+0x3a panic(c0c3feac,0,c0c3fe43,70,ea60,...) at panic+0x136 run_interrupt_driven_config_hooks(0,181ec00,181ec00,181e000,1825000,...) at run_interrupt_driven_config_hooks+0x1c7 mi_startup() at mi_startup+0x96 begin()at begin+0x2c db> My original emails are here: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1705690+0+/usr/local/www/db/text/2009/freebsd-questions/20090517.freebsd-questions http://docs.freebsd.org/cgi/getmsg.cgi?fetch=166763+0+current/freebsd-questions Thanks Chris From korvus at comcast.net Fri May 22 12:35:38 2009 From: korvus at comcast.net (Steve Polyack) Date: Fri May 22 12:35:44 2009 Subject: libraw1394 and FreeBSD Message-ID: <4A169891.5080609@comcast.net> Hello, I've seen a few posts in the archives referring to porting libraw1394 to FreeBSD. However, none of these appear to have been successful. I'm considering giving this a shot, but I will likely need some guidance. I have a few questions/points from what I've gathered from past discussions: 1. libraw1394 implements some ISO 1394 read/write/stop/start/etc functions for firewire on linux. It's been said that these are already implemented in the FreeBSD kernel modules which provide firewire access. Is this correct? If so, libraw1394 only needs rewritten enough to provide the freebsd kernel interface in a linux application-familiar sense. 2. What is going on with firewire development in FreeBSD currently? If I attempt to complete this port, am I better off working with 8-CURRENT as opposed to 7.2-RELEASE? I'm aware the USB stack in 8 is totally rewritten; is the same true for the firewire modules? I believe this would be a valuable port for FreeBSD. It would enable us to use a wide range of audio and DV interfaces via firewire and existing linux "drivers" which only depend on libraw1394, opening up possibilities like using FreeBSD for audio and video editing. Thanks, Steve Polyack From sean.bruno at dsl-only.net Fri May 22 19:15:29 2009 From: sean.bruno at dsl-only.net (Sean Bruno) Date: Fri May 22 19:15:36 2009 Subject: libraw1394 and FreeBSD In-Reply-To: <4A169891.5080609@comcast.net> References: <4A169891.5080609@comcast.net> Message-ID: <1243019727.3373.16.camel@localhost.localdomain> On Fri, 2009-05-22 at 08:20 -0400, Steve Polyack wrote: > Hello, > I've seen a few posts in the archives referring to porting libraw1394 > to FreeBSD. However, none of these appear to have been successful. I'm > considering giving this a shot, but I will likely need some guidance. I > have a few questions/points from what I've gathered from past discussions: Excellent. I'm around, but a little swamped right now under other school related things. I hope to have some free time soon though. I've jotted down a few thoughts below. > 1. libraw1394 implements some ISO 1394 read/write/stop/start/etc > functions for firewire on linux. It's been said that these are already > implemented in the FreeBSD kernel modules which provide firewire > access. Is this correct? If so, libraw1394 only needs rewritten enough > to provide the freebsd kernel interface in a linux application-familiar > sense. > Take a look at how fwcontrol interfaces with the driver. Let me know if you would like to see some changes at the interface. > 2. What is going on with firewire development in FreeBSD currently? If > I attempt to complete this port, am I better off working with 8-CURRENT > as opposed to 7.2-RELEASE? I'm aware the USB stack in 8 is totally > rewritten; is the same true for the firewire modules? > Firewire is fairly static right now. I had hoped to start a bit of re-writing before 8.0 is released, but it's going to be cutting it close. I have been enhancing -Current only for the last few months, and I have been kind of ignoring 7 and 6. So the code has diverged a bit. If you can do it, please start with -Current and see what can be done there first. > > I believe this would be a valuable port for FreeBSD. It would enable us > to use a wide range of audio and DV interfaces via firewire and existing > linux "drivers" which only depend on libraw1394, opening up > possibilities like using FreeBSD for audio and video editing. Agreed. Let me know what devices you have access to. Sean From bugmaster at FreeBSD.org Mon May 25 11:06:50 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon May 25 11:07:51 2009 Subject: Current problem reports assigned to freebsd-firewire@FreeBSD.org Message-ID: <200905251106.n4PB6nGA092761@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- p kern/125673 firewire [firewire] [panic] FreeBSD7 panics when kldunloading f o kern/122951 firewire [firewire] video-transfer via fwcontrol triggers a pan o kern/118093 firewire [firewire] firewire bus reset hogs CPU, causing data t p kern/114646 firewire [firewire] [patch] firewire fails after suspend/resume o kern/113785 firewire [firewire] dropouts when playing DV on firewire o kern/97208 firewire [firewire] System hangs / locks up when a firewire dis o kern/74238 firewire [firewire] fw_rcv: unknown response; firewire ad-hoc w 7 problems total.