Fw: SATA drive lock-up
my verbose dmesg is in attached zip file, from today. my disks are connected with sata - pata converter based on marvel 88i8030 and one more question about ata3 and cable 40 wires, the cable actually is serial ata cable, not the 40 wires pata cable. and why it doesn't say then same thing about ata4 ? actually it's exactly same device like ata3? and to be strict ata1 is also 80 pins cable not 40 pins. ad4: setting UDMA100 on SiI 3112 chip GEOM: create disk ad4 dp=0xc6262670 ad4: IC35L120AVVA07-0/VA6OA52A ATA-5 disk at ata2-master ad4: 117800MB (241254720 sectors), 239340 C, 16 H, 63 S, 512 B ad4: 16 secs/int, 1 depth queue, UDMA100 GEOM: new disk ad4 ata3-master: pio=0x0c wdma=0x22 udma=0x45 cable=40pin - Original Message - From: Soren Schmidt [EMAIL PROTECTED] To: Derek Ragona [EMAIL PROTECTED] Cc: Putinas [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, September 25, 2003 09:32 Subject: Re: SATA drive lock-up It seems Derek Ragona wrote: Søren, My setup is as follows: Maxtor 6Y120MO 120GB SATA drive Adaptec Serial ATA RAID 1210SA Intel® Desktop Board D845GEBV2 1GB RAM 1.7 GHz Celeron CPU Ok, I'll try to get something semialr setup here and try to reproduce. If there is some way to get more debugging information, please let me know. If you want the ATA subsystem rebuilt differently for more debugging, I'm happy to do that as well. If you want access to the box, I will give you that too. Hmm debugging this kind of problems most often requires hands on access to the HW, in some cases the ability to hook up measuring/test equipment greatly enhances the problem hunting (or is the only way to catch it). -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] dmesg.zip Description: Binary data ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATANG Vs. Acer chipset
It seems Michael McGoldrick wrote: I haven't been able to boot a -current kernel since the ATAng import. They all die after (in a boot -v) a message from GEOM about creating ad0. If any further info would be helpful, just let me know what you need. I know there are a problem with *some* Acer chipsets, but so far I havn't found out why. I'll look into it as soon as I get time, but reallife is taking all my spare hours currently... -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Status of SCHED_ULE?
On Sat, Sep 27, 2003 at 11:31:25PM -0400, Jeff Roberson wrote: On Sat, 27 Sep 2003, Morten Rodal wrote: It has improved quite a bit lately, and is now also working with KSE. However, the mouse will get sluggish whenever the computer is under bursts of load (i.e. a compile) I have not had this experience. Can you give me details of your machine and the kind of load that causes slugishness? I'll correct it as soon as I can identify it. The machine is an dual Pentium 2 300MHz, and I'm running gnome 2.4. I do also experience this with my computer at school, a single Pentium3 733MHz. The load isn't very complicated, usually just gnome 2.4 and mozilla firebird running. If I then do anything that requires lots of cpu, like a compile of a program, the interactivity drops fast. On the dual machine I have also experienced a *HUGE* increase in the time for portupgrade -ar to complete. I am not familiar with how portupgrade works, but it seems to spawn a few make's and sort's, but I am not sure why it is currently using 3 hours instead of 10 minutes to complete! (This was tested when there was no packages to upgrade, which shouldn't take long) Both machines (this dual and the one at school) are running with a libmap.conf in order to use libkse, is this perhaps affecting the performance of ULE? I am not sure how useful this is to you, but if you have any other pointers as to what I should look at just ask. -- Morten Rodal ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
UMASS: fatal trap while unplugging floppy drive
Hi I cvsupped this morning and rebuilt world and kernel... When I unplug the USB floppy drive, I get the following umass0: at uhub1 port 1 (addr 2) disconnected (da0:umass-sim0:0:0:0): lost device (da0:umass-sim0:0:0:0): removing device entry GEOM: destroy disk da0 dp=0xc40b6450 Fatal trap 12: page fault while in kernel mode fault virtual address = 0x2c fault code = supervisor read, page not present instruction pointer = 0x8:0xc05fc8b7 stack pointer = 0x10:0xd7151b68 frame pointer = 0x10:0xd7151b70 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 = 29 (usb1) kernel: type 12 trap, code=0 Stopped at cam_periph_invalidate_0xc: testb $0x8,0x2c(%bx) db trace cam_periph_invalidate(0,c06205b5,0,,) at cam_periph_invalidate+0xc targbhasync(0,40,d7151c1c,0,0) at targbhasync_0xdd xpt_async_bcast(c150de70,40,d7151c1c,0,0) at xpt_async_bcast+0x3c xpt_bus_deregister(0,d7151c4c,c44390a8,d7151c5c,c44a9d7f) at xpt_bus_deregister+0x6e umass_cam_detach_sim(c445,c44390a8,c442b200,c442b200,d7151cb0) at umass_cam_detach_sim+0x21 umass_detach(c442b200,c44390a8,c02ff818,c442b200,0) at umass_detach+0x31 device_detach(c3fde8b0,c3fdec00,11,186,c018505b) at device_detach+0x6e uhub_explore(c3fde980,c3fcdd00,d7151d18,c04046d7,c3fcdd00) at uhub_explore+0x17c usb_discover(c3fcdd00,0,5c,c0416ce8,1770) at usb_discover+0x36 usb_event_thread(c3fcdd00,d7151d48,c02c47bb,314,c3fcdd00) at usb_event_thread+0x62 fork_exit() at fork_exit+0xaf -- Antony T Curtis BSc Unix Analyst Programmer http://homepage.ntlworld.com/antony.t.curtis/ signature.asc Description: This is a digitally signed message part
more panics from current (partII)
After adding more disks to this system it dies continously. Last two traces look quite the same. Tomppa ---clipclip--- login: kernel trap 19 with interrupts disabled NMI ... going to debugger kernel: type 19 trap, code=0 Stopped at rtcintr+0x57: callrtcin db trace rtcintr(0) at rtcintr+0x57 Xfastintr8() at Xfastintr8+0x68 --- interrupt, eip = 0xc037ed02, esp = 0xcd680cdc, ebp = 0xcd680cdc --- cpu_idle(73042444,890002c0,bde8241c,c780,10c2444) at cpu_idle+0x22 idle_proc(0,cd680d48,c700,50082444,c7df) at idle_proc+0x25 fork_exit(c01ecd40,0,cd680d48) at fork_exit+0xb1 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xcd680d7c, ebp = 0 --- db rtcintr(0) at rtcintr+0x57 Xfastintr8() at Xfastintr8+0x68 --- interrupt, eip = 0xc037ed02, esp = 0xcd680cdc, ebp = 0xcd680cdc --- db panic panic: from debugger Debugger(panic) Fatal trap 3: breakpoint instruction fault while in kernel mode instruction pointer = 0x8:0xc0375b34 stack pointer = 0x10:0xcd680a80 frame pointer = 0x10:0xcd680a8c code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= IOPL = 0 current process = 11 (idle) Stopped at rtcintr+0x57: callrtcin db panic: from debugger Uptime: 7h17m58s Dumping 255 MB 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 Dump complete Shutting down ACPI Automatic reboot in 15 seconds - press a key on the console to abort -- Press a key on the console to reboot, -- or switch off the system now. Rebooting... ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: UMASS: fatal trap while unplugging floppy drive
On Sun, 2003-09-28 at 11:48, John-Mark Gurney wrote: Antony T Curtis wrote this message on Sun, Sep 28, 2003 at 11:34 +0100: I cvsupped this morning and rebuilt world and kernel... When I unplug the USB floppy drive, I get the following Did you have the filesystem mounted? Right now USB is not at all safe for hot plugging. If the recent move to GEOM, it may make unplugging devices even more dangerous. You might try ejecting the media through camcontrol before unplugging the drive. (or even physically ejecting it) The filesystem was not mounted - I used mtools to examine the disk. Plugging in seemed to work fine. I just cannot unplug. patches welcome! :) I'll probably take a peek... -- Antony T Curtis BSc Unix Analyst Programmer http://homepage.ntlworld.com/antony.t.curtis/ signature.asc Description: This is a digitally signed message part
Re: Status of SCHED_ULE?
Morten Rodal wrote: On Sat, Sep 27, 2003 at 11:31:25PM -0400, Jeff Roberson wrote: On Sat, 27 Sep 2003, Morten Rodal wrote: It has improved quite a bit lately, and is now also working with KSE. However, the mouse will get sluggish whenever the computer is under bursts of load (i.e. a compile) I have not had this experience. Can you give me details of your machine and the kind of load that causes slugishness? I'll correct it as soon as I can identify it. The machine is an dual Pentium 2 300MHz, and I'm running gnome 2.4. I do also experience this with my computer at school, a single Pentium3 733MHz. The load isn't very complicated, usually just gnome 2.4 and mozilla firebird running. If I then do anything that requires lots of cpu, like a compile of a program, the interactivity drops fast. On the dual machine I have also experienced a *HUGE* increase in the time for portupgrade -ar to complete. I am not familiar with how portupgrade works, but it seems to spawn a few make's and sort's, but I am not sure why it is currently using 3 hours instead of 10 minutes to complete! (This was tested when there was no packages to upgrade, which shouldn't take long) Both machines (this dual and the one at school) are running with a libmap.conf in order to use libkse, is this perhaps affecting the performance of ULE? I am not sure how useful this is to you, but if you have any other pointers as to what I should look at just ask. Are you running 5.1-release or 5.1-current? I ask because I have used ULE on two different kernels so far on this box. One was 5.1-release running gnome2, mozilla, xmms. On this the mouse stutters really badly whenever anything is being compiled. However on the 5.1-current kernel this behavior no longer happens and the mouse is fine. I suspect ULE has had a few enhancements between the release and now. Matt. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Status of SCHED_ULE?
On Sun, Sep 28, 2003 at 01:26:24PM +0100, Matt wrote: Morten Rodal wrote: On Sat, Sep 27, 2003 at 11:31:25PM -0400, Jeff Roberson wrote: On Sat, 27 Sep 2003, Morten Rodal wrote: It has improved quite a bit lately, and is now also working with KSE. However, the mouse will get sluggish whenever the computer is under bursts of load (i.e. a compile) I have not had this experience. Can you give me details of your machine and the kind of load that causes slugishness? I'll correct it as soon as I can identify it. The machine is an dual Pentium 2 300MHz, and I'm running gnome 2.4. I do also experience this with my computer at school, a single Pentium3 733MHz. The load isn't very complicated, usually just gnome 2.4 and mozilla firebird running. If I then do anything that requires lots of cpu, like a compile of a program, the interactivity drops fast. On the dual machine I have also experienced a *HUGE* increase in the time for portupgrade -ar to complete. I am not familiar with how portupgrade works, but it seems to spawn a few make's and sort's, but I am not sure why it is currently using 3 hours instead of 10 minutes to complete! (This was tested when there was no packages to upgrade, which shouldn't take long) Both machines (this dual and the one at school) are running with a libmap.conf in order to use libkse, is this perhaps affecting the performance of ULE? I am not sure how useful this is to you, but if you have any other pointers as to what I should look at just ask. Are you running 5.1-release or 5.1-current? I ask because I have used ULE on two different kernels so far on this box. One was 5.1-release running gnome2, mozilla, xmms. On this the mouse stutters really badly whenever anything is being compiled. However on the 5.1-current kernel this behavior no longer happens and the mouse is fine. I suspect ULE has had a few enhancements between the release and now. I am running 5.1-current Dual machine: FreeBSD slurp.rodal.no 5.1-CURRENT FreeBSD 5.1-CURRENT #3: Thu Sep 25 04:03:23 CEST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/slurp i386 School computer: FreeBSD hauk10.idi.ntnu.no 5.1-CURRENT FreeBSD 5.1-CURRENT #2: Fri Sep 26 09:12:55 CEST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/hauk10 i386 -- Morten Rodal ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Status of SCHED_ULE?
Morten Rodal wrote: On Sun, Sep 28, 2003 at 01:26:24PM +0100, Matt wrote: Morten Rodal wrote: On Sat, Sep 27, 2003 at 11:31:25PM -0400, Jeff Roberson wrote: On Sat, 27 Sep 2003, Morten Rodal wrote: It has improved quite a bit lately, and is now also working with KSE. However, the mouse will get sluggish whenever the computer is under bursts of load (i.e. a compile) I have not had this experience. Can you give me details of your machine and the kind of load that causes slugishness? I'll correct it as soon as I can identify it. The machine is an dual Pentium 2 300MHz, and I'm running gnome 2.4. I do also experience this with my computer at school, a single Pentium3 733MHz. The load isn't very complicated, usually just gnome 2.4 and mozilla firebird running. If I then do anything that requires lots of cpu, like a compile of a program, the interactivity drops fast. On the dual machine I have also experienced a *HUGE* increase in the time for portupgrade -ar to complete. I am not familiar with how portupgrade works, but it seems to spawn a few make's and sort's, but I am not sure why it is currently using 3 hours instead of 10 minutes to complete! (This was tested when there was no packages to upgrade, which shouldn't take long) Both machines (this dual and the one at school) are running with a libmap.conf in order to use libkse, is this perhaps affecting the performance of ULE? I am not sure how useful this is to you, but if you have any other pointers as to what I should look at just ask. Are you running 5.1-release or 5.1-current? I ask because I have used ULE on two different kernels so far on this box. One was 5.1-release running gnome2, mozilla, xmms. On this the mouse stutters really badly whenever anything is being compiled. However on the 5.1-current kernel this behavior no longer happens and the mouse is fine. I suspect ULE has had a few enhancements between the release and now. I am running 5.1-current Dual machine: FreeBSD slurp.rodal.no 5.1-CURRENT FreeBSD 5.1-CURRENT #3: Thu Sep 25 04:03:23 CEST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/slurp i386 School computer: FreeBSD hauk10.idi.ntnu.no 5.1-CURRENT FreeBSD 5.1-CURRENT #2: Fri Sep 26 09:12:55 CEST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/hauk10 i386 Ahh I tell you the other difference. I had a USB mouse when I tried ULE with 5.1-release and it stuttered. It's just a ps2 one on the current kernel where it's not stuttering. Matt. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Status of SCHED_ULE?
On Sunday 28 September 2003 14:38, Matt wrote: Morten Rodal wrote: On Sun, Sep 28, 2003 at 01:26:24PM +0100, Matt wrote: Morten Rodal wrote: On Sat, Sep 27, 2003 at 11:31:25PM -0400, Jeff Roberson wrote: On Sat, 27 Sep 2003, Morten Rodal wrote: It has improved quite a bit lately, and is now also working with KSE. However, the mouse will get sluggish whenever the computer is under bursts of load (i.e. a compile) I have not had this experience. Can you give me details of your machine and the kind of load that causes slugishness? I'll correct it as soon as I can identify it. The machine is an dual Pentium 2 300MHz, and I'm running gnome 2.4. I do also experience this with my computer at school, a single Pentium3 733MHz. The load isn't very complicated, usually just gnome 2.4 and mozilla firebird running. If I then do anything that requires lots of cpu, like a compile of a program, the interactivity drops fast. On the dual machine I have also experienced a *HUGE* increase in the time for portupgrade -ar to complete. I am not familiar with how portupgrade works, but it seems to spawn a few make's and sort's, but I am not sure why it is currently using 3 hours instead of 10 minutes to complete! (This was tested when there was no packages to upgrade, which shouldn't take long) Both machines (this dual and the one at school) are running with a libmap.conf in order to use libkse, is this perhaps affecting the performance of ULE? I am not sure how useful this is to you, but if you have any other pointers as to what I should look at just ask. Are you running 5.1-release or 5.1-current? I ask because I have used ULE on two different kernels so far on this box. One was 5.1-release running gnome2, mozilla, xmms. On this the mouse stutters really badly whenever anything is being compiled. However on the 5.1-current kernel this behavior no longer happens and the mouse is fine. I suspect ULE has had a few enhancements between the release and now. I am running 5.1-current Dual machine: FreeBSD slurp.rodal.no 5.1-CURRENT FreeBSD 5.1-CURRENT #3: Thu Sep 25 04:03:23 CEST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/slurp i386 School computer: FreeBSD hauk10.idi.ntnu.no 5.1-CURRENT FreeBSD 5.1-CURRENT #2: Fri Sep 26 09:12:55 CEST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/hauk10 i386 Ahh I tell you the other difference. I had a USB mouse when I tried ULE with 5.1-release and it stuttered. It's just a ps2 one on the current kernel where it's not stuttering. Matt. I have a PS/2 mouse, I run -CURRENT from 2 days ago, and I experience the stuttering too. It happens when compiling stuff, when loading complicated pages in Mozilla Firebird, and when logging out of GNOME 2.4 (the 'background fade' animation brings my Athlon XP 2000+ to its knees when I use SCHED_ULE). Arjan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Status of SCHED_ULE?
I have not had this experience. Can you give me details of your machine and the kind of load that causes slugishness? I'll correct it as soon as I can identify it. Using Linux-Firebird with some Java applets shows this effect, i.e. completelly bogging down X to a unusable state. Also, it's very easy to archive if you stress some ata-disks. In particular, if I copy a big (1 GB) file from ad0: 114473MB ST3120023A [232581/16/63] at ata0-master UDMA100 to ad2: 57259MB MAXTOR 4K060H3 [116336/16/63] at ata1-master UDMA100 or vice versa, X will completely unresponsive until the the copy is finnished. A same kernel with the 4BSD scheduler doesn't show this, so I don't think it's hardware related. Alex ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Status of SCHED_ULE?
Il Dom, 2003-09-28 alle 15:45, Arjan van Leeuwen ha scritto: Ahh I tell you the other difference. I had a USB mouse when I tried ULE with 5.1-release and it stuttered. It's just a ps2 one on the current kernel where it's not stuttering. Matt. I have a PS/2 mouse, I run -CURRENT from 2 days ago, and I experience the stuttering too. It happens when compiling stuff, when loading complicated pages in Mozilla Firebird, and when logging out of GNOME 2.4 (the 'background fade' animation brings my Athlon XP 2000+ to its knees when I use SCHED_ULE). Same problem here, with a PS/2 Mouse on my Athlon XP 2000+, usign Firebird, Ximian Evolution and others applications with SCHED_ULE. -- Rionda aka Matteo Riondato G.U.F.I Staff Member (http://www.gufi.org) BSD-FAQ-it Main Developer (http://www.gufi.org/~rionda) GPG key at: http://www.riondabsd.net/riondagpg.asc Sent from: kaiser.sig11.org running FreeBSD-5.1-CURRENT signature.asc Description: Questa parte del messaggio =?ISO-8859-1?Q?=E8?= firmata
uplcom driver and USB modem
I've recently been trying to get my USB modem working in FreeBSD -CURRENT, without much success. In Linux, I can load the pl2303 driver and a ttyUSB0 device node is then used to communicate with the modem as if were attached to a serial port. In FreeBSD, I load the uplcom driver and the Prolific PL-2303 device is found and a ucom0 node gets created, but after that there doesn't seem to be any communications with the modem. Is the uplcom driver broken for my Jetway modem, or is there something I can do to get comms working? I know I should probably get a 'proper' serial modem, but I'd like to know if it's at all possible to get my current modem working. -- Bruce Cran ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Status of SCHED_ULE?
Hi ! I have a PS/2 mouse, I run -CURRENT from 2 days ago, and I experience the stuttering too. Me too, though I have to relativize this. My configuration is UP with a pentium 4, 2.4 GHz running gnome2, evolution, mozilla and some gnome-terminals. With 4BSD, the mouse cycles through non-responding, jumping and smoothly sliding under compilation load. Whereas under ULE, it is sort of constantly stuttering. On the other hand I experienced satisfactory responsiveness even under a load of 4, one of the most irritating exceptions being the stuttering mouse (though with 4BSD, responsiveness is beyond all hope...) There is another exception which is far more frustrating. Using vi (or view) on a file and typing 'j' on the last line. It'll take approximately half a second per line scrolling by. (Still talking of compilation load here.) Cheers Peter ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Status of SCHED_ULE?
On Sunday 28 September 2003 16.40, Peter Kadau wrote: Hi ! I have a PS/2 mouse, I run -CURRENT from 2 days ago, and I experience the stuttering too. Me too, though I have to relativize this. My configuration is UP with a pentium 4, 2.4 GHz running gnome2, evolution, mozilla and some gnome-terminals. I am running --current on my laptop which is 2.5 Ghz P4 / 512 MB RAM, and during buildworld/or make install of the KDE metaport I have no problems at all using _ULE If I cp or mv a large file 2GB or larger I still see no problems -- Matt Douhan www.fruitsalad.org [EMAIL PROTECTED] ping elvis elvis is alive ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re[2]: Sil680 RAID Support while installing 5.1-Release
Hello Derek, Saturday, September 27, 2003, 8:50:21 PM, you wrote: Gabriel, I experienced the same problem using 5.1 release with an Adaptec SATA Raid card that uses the SATA Sil3112A chip. With 5.1-CURRENT I can get FreeBSD to install, but the server locks-up because the disk subsystem gets a DMA write error that it either never recovers from or falls into the debugger (most times it does NOT go to the debugger.) There are a few of us using SATA Sil3112A chips and experiencing these problems. It seems to boot ok with the latest snapshot boot cd from current.freebsd.org HOWEVER whatever I do, the disks will show up individually in the setup and not as array. Best regards, Gabriel ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
TEST PLEASE: if_tap patch
There is now also another patch http://phk.freebsd.dk/patch/if_tap.patch for the /dev/tap and /dev/vmnet driver. Please test this too, it follows the if_tun patch very closely. Please test this patch: http://phk.freebsd.dk/patch/if_tun.patch There is a slight change in semantics in that the interface will disappear entirely when the /dev/tun%d device is closed. If no objections this will be committed in some days. | Remove the bogus tunbasedev, instead record the dev_t in our softc. | | Rely on the new an cloning friendlier semantics of make_dev(). | | Properly dismantle and remove the interface and destroy the dev_t | at last close of the device. | | Remove code from MOD_UNLOAD to dismantle things. | | Remove the list used to hang the tunnels from, it is no longer needed. -- 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] -- 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]
HEADSUP: Change of makedev() semantics.
I am in the process of adding ref-counting and locking to dev_t, and would very much prefer if we could get this step completed soon before 5-STABLE gets branched. All this will be transparent to the majority of device drivers, as the refcounting will happen in the make_dev() and destroy_dev() family of calls and normal drivers need not know more about it. But there are a few remaining users of makedev() which get in the way of this effort, and we must get these fixed. Basically: 1. Do not call makedev(). 2. If you do cloning, please look at the patches I posted for if_tun/if_tap for how to do it. 3. If you do a normal device driver, cache the result from when you call make_dev(). 4. If you translate foreign dev_t's, ie emulators or compat code, contact me. I'm not sure I understand how this works and should work and we need to talk. 5. If anything else or in doubt, ask me. Can I see some volounteers and/or maintainers please ? ./alpha/osf1/osf1_misc.c badly named local macro ? ./compat/linux/linux_stats.c ./compat/svr4/svr4_types.h compat code, not sure that this is correct now. Must be supported by new finddev semantics. ./dev/ata/atapi-cd.c cloning related to root mount. gets fixed when phk GEOMify the driver. ./dev/sound/midi/midi.h Not sure. ./dev/nmdm/nmdm.c pseudo-cloning. Should do real cloning. ./dev/syscons/syscons.c Related to console initialization. Maybe tricky. ./dev/sound/pcm/dsp.c ./dev/sound/pcm/mixer.c ./dev/usb/ugen.c ./dev/usb/uscanner.c Failure to cache result of make_dev() ./dev/vinum Failure to cache result of make_dev() ? Thanks in advance! -- 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: HEADSUP: Change of makedev() semantics.
On Sunday, 28 September 2003 at 23:22:07 +0200, Poul-Henning Kamp wrote: Basically: 3. If you do a normal device driver, cache the result from when you call make_dev(). ... ./dev/vinum Failure to cache result of make_dev() ? Where should this be cached? Can you point to example code? Greg -- See complete headers for address and phone numbers. NOTE: Due to the currently active Microsoft-based worms, I am limiting all incoming mail to 131,072 bytes. This is enough for normal mail, but not for large attachments. Please send these as URLs. pgp0.pgp Description: PGP signature
Re: HEADSUP: Change of makedev() semantics.
On Sun, Sep 28, 2003 at 11:22:07PM +0200, Poul-Henning Kamp wrote: I am in the process of adding ref-counting and locking to dev_t, and would very much prefer if we could get this step completed soon before 5-STABLE gets branched. All this will be transparent to the majority of device drivers, as the refcounting will happen in the make_dev() and destroy_dev() family of calls and normal drivers need not know more about it. But there are a few remaining users of makedev() which get in the way of this effort, and we must get these fixed. Basically: 1. Do not call makedev(). 2. If you do cloning, please look at the patches I posted for if_tun/if_tap for how to do it. 3. If you do a normal device driver, cache the result from when you call make_dev(). 4. If you translate foreign dev_t's, ie emulators or compat code, contact me. I'm not sure I understand how this works and should work and we need to talk. 5. If anything else or in doubt, ask me. Can I see some volounteers and/or maintainers please ? ./alpha/osf1/osf1_misc.c badly named local macro ? Unused code. umakedev is used within a macro but nowhere defined it seems. makedev is used as a macroname, but ifdef'ed 0. Shouldn't hurt. Maybe someone with knowledge about OSF1 emulation should decide what happens with them in the long run. ./dev/usb/ugen.c ./dev/usb/uscanner.c Failure to cache result of make_dev() I'll take those. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADSUP: Change of makedev() semantics.
On Mon, 29 Sep 2003, Greg 'groggy' Lehey wrote: On Sunday, 28 September 2003 at 23:22:07 +0200, Poul-Henning Kamp wrote: Basically: 3. If you do a normal device driver, cache the result from when you call make_dev(). ... ./dev/vinum Failure to cache result of make_dev() ? Where should this be cached? Can you point to example code? Actually, it looks like Vinum is caching the dev_t's, but it's not always using them to get back to the dev_t--sometimes it's invoking makedev() instead. However, this appears to happen only in the vinumrevive.c code, so I'm not sure if that's a property of the cached reference being unavailable -- it looks like it should be available in that context though. I.e., using sd-dev instead of VINUM_SD() -- it looks like there is a valid (struct sd *) reference there to follow, so you can get to the dev_t without doing a makedev(). Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADSUP: Change of makedev() semantics.
On Sunday, 28 September 2003 at 19:46:20 -0400, Robert Watson wrote: On Mon, 29 Sep 2003, Greg 'groggy' Lehey wrote: On Sunday, 28 September 2003 at 23:22:07 +0200, Poul-Henning Kamp wrote: Basically: 3. If you do a normal device driver, cache the result from when you call make_dev(). ... ./dev/vinum Failure to cache result of make_dev() ? Where should this be cached? Can you point to example code? Actually, it looks like Vinum is caching the dev_t's, Ah, you mean saving the results rather than calling make_dev() every time? Yes, it only calls make_dev() once for any device. but it's not always using them to get back to the dev_t--sometimes it's invoking makedev() instead. However, this appears to happen only in the vinumrevive.c code, so I'm not sure if that's a property of the cached reference being unavailable it looks like it should be available in that context though. No, it should always be available. I was going to say I don't see any references to make_dev() in vinumrevive.c, nor any references to makedev() at all, but I see that VINUM_SD includes both. I.e., using sd-dev instead of VINUM_SD() -- it looks like there is a valid (struct sd *) reference there to follow, so you can get to the dev_t without doing a makedev(). Yes, this is a bug (and an indication of the dangers of using macros :-) I'll fix it. Greg -- See complete headers for address and phone numbers. NOTE: Due to the currently active Microsoft-based worms, I am limiting all incoming mail to 131,072 bytes. This is enough for normal mail, but not for large attachments. Please send these as URLs. pgp0.pgp Description: PGP signature
Re: TEST PLEASE: if_tun patch
On Sat, Sep 27, 2003 at 11:57:19PM +0200, Poul-Henning Kamp wrote: Please test this patch: http://phk.freebsd.dk/patch/if_tun.patch There is a slight change in semantics in that the interface will disappear entirely when the /dev/tun%d device is closed. If no objections this will be committed in some days. | Properly dismantle and remove the interface and destroy the dev_t | at last close of the device. I'm not convinced this is the right direction to move in. The problem is that users are beginning to expect that pseudo-interfaces be created with network interface cloning, but tun, tap, and vmnet aren't. I'm concerned that this destroy on last close semantic will make it harder to implement that. I guess if we moved to a model where we allowed both methods to work, we could somehow add an extra reference when we cloned interfaces via ifconfig if create, but I don't know the devfs side well enough to know if that's possible. This doesn't constitute an objection since I've had over a year to fix these drivers, but I'd appreciate it if you would give it some thought. -- Brooks P.S. Since you're moving it anyway, we make the assumption in the network code that the ifnet struct is the first member of the softc so you might want to fix tun while you're there. See the comment around if_var.h:111. -- Any statement of the form X is the one, true Y is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 pgp0.pgp Description: PGP signature
Re: Status of SCHED_ULE?
On Sun, 28 Sep 2003, Morten Rodal wrote: On Sat, Sep 27, 2003 at 11:31:25PM -0400, Jeff Roberson wrote: On Sat, 27 Sep 2003, Morten Rodal wrote: It has improved quite a bit lately, and is now also working with KSE. However, the mouse will get sluggish whenever the computer is under bursts of load (i.e. a compile) I have not had this experience. Can you give me details of your machine and the kind of load that causes slugishness? I'll correct it as soon as I can identify it. The machine is an dual Pentium 2 300MHz, and I'm running gnome 2.4. I do also experience this with my computer at school, a single Pentium3 733MHz. The load isn't very complicated, usually just gnome 2.4 and mozilla firebird running. If I then do anything that requires lots of cpu, like a compile of a program, the interactivity drops fast. On the dual machine I have also experienced a *HUGE* increase in the time for portupgrade -ar to complete. I am not familiar with how portupgrade works, but it seems to spawn a few make's and sort's, but I am not sure why it is currently using 3 hours instead of 10 minutes to complete! (This was tested when there was no packages to upgrade, which shouldn't take long) Both machines (this dual and the one at school) are running with a libmap.conf in order to use libkse, is this perhaps affecting the performance of ULE? It could be. Can you try with libthr or libc_r and let me know? I am not sure how useful this is to you, but if you have any other pointers as to what I should look at just ask. -- Morten Rodal ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Status of SCHED_ULE?
On Sun, 28 Sep 2003, Arjan van Leeuwen wrote: On Sunday 28 September 2003 14:38, Matt wrote: Morten Rodal wrote: On Sun, Sep 28, 2003 at 01:26:24PM +0100, Matt wrote: Morten Rodal wrote: On Sat, Sep 27, 2003 at 11:31:25PM -0400, Jeff Roberson wrote: On Sat, 27 Sep 2003, Morten Rodal wrote: It has improved quite a bit lately, and is now also working with KSE. However, the mouse will get sluggish whenever the computer is under bursts of load (i.e. a compile) I have not had this experience. Can you give me details of your machine and the kind of load that causes slugishness? I'll correct it as soon as I can identify it. The machine is an dual Pentium 2 300MHz, and I'm running gnome 2.4. I do also experience this with my computer at school, a single Pentium3 733MHz. The load isn't very complicated, usually just gnome 2.4 and mozilla firebird running. If I then do anything that requires lots of cpu, like a compile of a program, the interactivity drops fast. On the dual machine I have also experienced a *HUGE* increase in the time for portupgrade -ar to complete. I am not familiar with how portupgrade works, but it seems to spawn a few make's and sort's, but I am not sure why it is currently using 3 hours instead of 10 minutes to complete! (This was tested when there was no packages to upgrade, which shouldn't take long) Both machines (this dual and the one at school) are running with a libmap.conf in order to use libkse, is this perhaps affecting the performance of ULE? I am not sure how useful this is to you, but if you have any other pointers as to what I should look at just ask. Are you running 5.1-release or 5.1-current? I ask because I have used ULE on two different kernels so far on this box. One was 5.1-release running gnome2, mozilla, xmms. On this the mouse stutters really badly whenever anything is being compiled. However on the 5.1-current kernel this behavior no longer happens and the mouse is fine. I suspect ULE has had a few enhancements between the release and now. I am running 5.1-current Dual machine: FreeBSD slurp.rodal.no 5.1-CURRENT FreeBSD 5.1-CURRENT #3: Thu Sep 25 04:03:23 CEST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/slurp i386 School computer: FreeBSD hauk10.idi.ntnu.no 5.1-CURRENT FreeBSD 5.1-CURRENT #2: Fri Sep 26 09:12:55 CEST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/hauk10 i386 Ahh I tell you the other difference. I had a USB mouse when I tried ULE with 5.1-release and it stuttered. It's just a ps2 one on the current kernel where it's not stuttering. Matt. I have a PS/2 mouse, I run -CURRENT from 2 days ago, and I experience the stuttering too. It happens when compiling stuff, when loading complicated pages in Mozilla Firebird, and when logging out of GNOME 2.4 (the 'background fade' animation brings my Athlon XP 2000+ to its knees when I use SCHED_ULE). Arjan Gnome seems to be a common theme. Are you also using libkse? There could be some interaction there. Thanks, Jeff ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADSUP: Change of makedev() semantics.
In message [EMAIL PROTECTED], Greg 'groggy' Lehey writes: --yRA+Bmk8aPhU85Qt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sunday, 28 September 2003 at 23:22:07 +0200, Poul-Henning Kamp wrote: Basically: 3. If you do a normal device driver, cache the result from when you call make_dev(). ... ./dev/vinum Failure to cache result of make_dev() ? Where should this be cached? Can you point to example code? Almost any other device driver. It is usually stored in the softc structure. -- 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: more panics from current (partII)
Tomi Vainio - Sun Finland [EMAIL PROTECTED] writes: After adding more disks to this system it dies continously. Last two traces look quite the same. Tomppa ---clipclip--- login: kernel trap 19 with interrupts disabled NMI ... going to debugger An NMI almost certainly indicates a hardware failure. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: TEST PLEASE: if_tun patch
In message [EMAIL PROTECTED], Brooks Davis writes: | Properly dismantle and remove the interface and destroy the dev_t=20 | at last close of the device. I'm not convinced this is the right direction to move in. The problem is that users are beginning to expect that pseudo-interfaces be created with network interface cloning, but tun, tap, and vmnet aren't. I'm totally don't-care on the semantics of any and all of these, my patch is just an attempt to evict makedev() from the tree. If you have a better idea how to do this, by all means go for it. It has also been pointed out that my subsequent if_tap.c patch would likely break the way people expect the vmnet device to work so I have already canned that. -- 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: more panics from current (partII)
On Sun, 28 Sep 2003 08:27 pm, Tomi Vainio - Sun Finland wrote: After adding more disks to this system it dies continously. Last two traces look quite the same. Tomppa It could be a power supply on the way out. I had an old dual P-166 that rebooted misterously until I took out two CD-ROM drives I wanted for another machine. (replaced the power supply, and refitted the CDROMS, and every thing worked ok.) Lucas ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
