Serial debug broken in recent -CURRENT?
After building a new kernel, remote serial gdb no longer works. When I issue a 'continue' command, I lose control of the system, but it doesn't continue running. Has anybody else seen this? 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: Status of SCHED_ULE?
On Monday 29 September 2003 07:05, Jeff Roberson wrote: > 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. Yes, I'm using libkse. It's also worth mentioning that it also happens in KDE, but only under the heavy load of a 'make buildworld' or compiling something else, or when for example extracting a big bzip2 file. Arjan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
gkrellm and libthr
Hi Just tried run gnome-2.4 desktop with: % cat /etc/libmap.conf libc_r.so.5 libthr.so.1 libc_r.solibthr.so All seems smooth so far, but gkrellm. First it works right (creates some threads) Then system time consumed became all available CPU power (by systat -vm) When I have kill gkrellm all returns to normal operation. It is reproducible effect. -- Vladimir B. Grebenschikov <[EMAIL PROTECTED]> SWsoft Inc. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
procfs problem
Hello
i have problem with /proc
i already have
options PROCFS
options PSEUDOFS
in kernel
but get these messages
~~~cut~~~
map02# strace -p 730
strace: open("/proc/...", ...): No such file or directory
trouble opening proc file
map02# truss -p 730
truss: cannot open /proc/730/mem: No such file or directory
map02# ps aux | grep 730
root 730 0.0 1.0 3476 2448 ?? Ss8:40AM 0:00.21
/usr/sbin/sshd
map02# uname -a
FreeBSD map02.modrany.czf 5.1-CURRENT FreeBSD 5.1-CURRENT #5: Sun Sep 28
23:37:08 CEST 2003
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/ROUTER i386
~~~cut~~~
the same messages i get also at
5.1-RELEASE-p3 FreeBSD 5.1-RELEASE-p3 #2: Wed Sep 17 00:17:40 CEST 2003
box
any ideas or do i something wrong? (forget I read anything about new
procfs - sorry if yes ...) ?
thaks for reply
Jiri
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: procfs problem
You must mount procfs.
# fstab;
proc/proc procfs rw 0 0
harti
On Mon, 29 Sep 2003, Jiri Mikulas wrote:
JM>Hello
JM>i have problem with /proc
JM>i already have
JM>
JM>options PROCFS
JM>options PSEUDOFS
JM>
JM>in kernel
JM>but get these messages
JM>~~~cut~~~
JM>map02# strace -p 730
JM>strace: open("/proc/...", ...): No such file or directory
JM>trouble opening proc file
JM>map02# truss -p 730
JM>truss: cannot open /proc/730/mem: No such file or directory
JM>map02# ps aux | grep 730
JM>root 730 0.0 1.0 3476 2448 ?? Ss8:40AM 0:00.21
JM>/usr/sbin/sshd
JM>map02# uname -a
JM>FreeBSD map02.modrany.czf 5.1-CURRENT FreeBSD 5.1-CURRENT #5: Sun Sep 28
JM>23:37:08 CEST 2003
JM>[EMAIL PROTECTED]:/usr/obj/usr/src/sys/ROUTER i386
JM>~~~cut~~~
JM>the same messages i get also at
JM>5.1-RELEASE-p3 FreeBSD 5.1-RELEASE-p3 #2: Wed Sep 17 00:17:40 CEST 2003
JM>box
JM>
JM>any ideas or do i something wrong? (forget I read anything about new
JM>procfs - sorry if yes ...) ?
JM>thaks for reply
JM>Jiri
JM>
JM>___
JM>[EMAIL PROTECTED] mailing list
JM>http://lists.freebsd.org/mailman/listinfo/freebsd-current
JM>To unsubscribe, send any mail to "[EMAIL PROTECTED]"
JM>
--
harti brandt,
http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private
[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: procfs problem
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> JM>map02# strace -p 730
> JM>strace: open("/proc/...", ...): No such file or directory
> JM>trouble opening proc file
> You must mount procfs.
>
> # fstab;
> proc /proc procfs rw 0 0
The bi-weekly status messages have been claiming that all the common
debugging tools except for truss have been converted to work without
procfs, since procfs is now deprecated. Does that not include strace, or
is there something else wrong here?
-Jason
--
Freud himself was a bit of a cold fish, and one cannot avoid the suspicion
that he was insufficiently fondled when he was an infant.
-- Ashley Montagu
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (FreeBSD)
Comment: See https://private.idealab.com/public/jason/jason.gpg
iD8DBQE/eBpHswXMWWtptckRAgSoAJ9IcIadlSRauyYJQHDc9GinZ20YCACfVGf1
ysBa4h7i4d99kPhr4xBdfZ8=
=7431
-END PGP SIGNATURE-
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: procfs problem
On Mon, Sep 29, 2003 at 04:40:54AM -0700, Jason Stone wrote:
>
> > JM>map02# strace -p 730
> > JM>strace: open("/proc/...", ...): No such file or directory
> > JM>trouble opening proc file
>
> > You must mount procfs.
> >
> > # fstab;
> > proc/proc procfs rw 0 0
>
> The bi-weekly status messages have been claiming that all the common
> debugging tools except for truss have been converted to work without
> procfs, since procfs is now deprecated. Does that not include strace, or
> is there something else wrong here?
strace is not part of FreeBSD.
Kris
pgp0.pgp
Description: PGP signature
5.2-RELEASE TODO
This is an automated bi-weekly mailing of the FreeBSD 5.2 open issues list. The live version of this list is available at: http://www.FreeBSD.org/releases/5.2R/todo.html Automated mailing of this list will continue through the release of FreeBSD 5.2. FreeBSD 5.2 Open Issues Open Issues This is a list of open issues that need to be resolved for FreeBSD 5.2. If you have any updates for this list, please e-mail [EMAIL PROTECTED] Must Resolve Issues for 5.2-RELEASE ++ |Issue| Status | Responsible |Description | |-+---+-+| | | | | KSE M:N threading | | | | | support is | | | | | reaching | | | | | experimental yet | | | | Julian | usable status on | | Production-quality | In| Elischer, David | i386 for | | M:N threading | progress | Xu, Daniel | 5.1-RELEASE. M:N | | | | Eischen | threading should | | | | | be productionable | | | | | and usable on all | | | | | platforms by | | | | | 5.2-RELEASE. | |-+---+-+| | | | | Kernel bits are| | | | | implemented but| | KSE support for | In| | untested. Userland | | sparc64 | progress | Jake Burkholder | bits are not | | | | | implemented. | | | | | Required for | | | | | 5.2-RELEASE. | |-+---+-+| | | | | Kernel and | | KSE support for | | Marcel | userland bits | | ia64| Complete. | Moolenaar | implemented but| | | | | unstable. Required | | | | | for 5.2-RELEASE. | |-+---+-+| | | | | Userland bits | | | | | implemented, | | KSE support for | In| Marcel | kernel bits not| | alpha | progress. | Moolenaar | implemented. | | | | | Required for | | | | | 5.2-RELEASE. | |-+---+-+| | | | | Kris Kennaway | | | | | reports high | | | | | instability of | | | | | 5-CURRENT on ia64 | | | | | machines, such as | | ia64 stability | In| Marcel | the pluto* | | | Progress | Moolenaar | machines. These| | | | | problems need to | | | | | be fixed in order | | | | | to get a | | | | | successful package | | | | | build. | |-+---+-+| | | | | A reworking of the | | | | | sio driver is | | | | | needed to support | | | | | serial terminal| | | | Marcel | devices on sparc64 | | New serial UART | In| Moolenaar, | and ia64 | | framework | progress | Warner Losh | platforms, among | | | | | others. This is| | | |
ICH sound after suspend/resume
Re: kern/55395 I see a patch to ich.c back on the 15th to "Correctly reset ich[3-5] sound cards on resume.", but I am still not able to properly use my sound card after a resume because the card starts clocking at the wrong rate, about 52K instead of the correct 48,000. There is nothing in the tying it to any PR, but it looks like it's trying to do the "right thing" on resume. As before, the sysctl for the sampling rate has no effect. Any ideas what I might try? -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Status of SCHED_ULE?
On Mon, Sep 29, 2003 at 01:04:49AM -0400, Jeff Roberson wrote: > 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 tried converting to libthr at school and started a "portupgrade -ar". (Of course I had restarted all the applications that uses threads) There was no difference in the interactivity, but I came to think of one other thing. I use the /dev/sysmouse and moused, not quite sure why but that's how I've always used my mouse (PS2 or USB) with FreeBSD. Could this have something to do with the mouse feeling sloppy? -- Morten Rodal ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ICH sound after suspend/resume
/-- "Kevin Oberman" wrote: | Re: kern/55395 | | I see a patch to ich.c back on the 15th to "Correctly reset ich[3-5] | sound cards on resume.", but I am still not able to properly use my | sound card after a resume because the card starts clocking at the wrong | rate, about 52K instead of the correct 48,000. | | There is nothing in the tying it to any PR, but it looks like it's | trying to do the "right thing" on resume. | | As before, the sysctl for the sampling rate has no effect. | | Any ideas what I might try? Kevin All I can suggest is going through the ICH sound docs. Intel write both register descriptions and programmers guide for their h/w. You might also look at the ALSA driver. I believe the speed problem most likely lies in the AC97 resets. I know I promised to look into this, but I've been struck by a shortage of time lately and don't see the situation improving in the near future. I'm very close to calling it a day with the commit bit. - Orion ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Serial debug broken in recent -CURRENT?
On Monday 29 September 2003 01:30 am, Greg 'groggy' Lehey wrote: > After building a new kernel, remote serial gdb no longer works. When > I issue a 'continue' command, I lose control of the system, but it > doesn't continue running. Has anybody else seen this? Yes, I noticed this late last week. I think it's been busted for <1 week. I tried to pinpoint the commit but ran out of time. Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ICH sound after suspend/resume
> From: Orion Hodson <[EMAIL PROTECTED]> > Date: Mon, 29 Sep 2003 08:29:38 -0700 > Sender: [EMAIL PROTECTED] > > /-- "Kevin Oberman" wrote: > | Re: kern/55395 > | > | I see a patch to ich.c back on the 15th to "Correctly reset ich[3-5] > | sound cards on resume.", but I am still not able to properly use my > | sound card after a resume because the card starts clocking at the wrong > | rate, about 52K instead of the correct 48,000. > | > | There is nothing in the tying it to any PR, but it looks like it's > | trying to do the "right thing" on resume. > | > | As before, the sysctl for the sampling rate has no effect. > | > | Any ideas what I might try? > > Kevin > > All I can suggest is going through the ICH sound docs. Intel write both > register descriptions and programmers guide for their h/w. You might also > look at the ALSA driver. I believe the speed problem most likely lies in the > AC97 resets. > > I know I promised to look into this, but I've been struck by a shortage of > time lately and don't see the situation improving in the near future. I'm > very close to calling it a day with the commit bit. I understand completely. I did not send the message because of impatience, but to make sure that you (and others) were aware that the patch of 9/15 did not fix the problem. If I get some time, I'll try looking at it, but my C skills are rusty and my familiarity with hardware (let alone BIOS) pretty much ends with DEC Alphas and VAXen. I've been living in the network world for 10 years and can talk in detail about the design of forwarding engines, but they have little in common with PCs. Thanks, -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: yep, umass still broken
What motherboards are you using with the OHCI controller? John-Mark Gurney (jmg@) and I kicked this around at bsdcon but couldn't reproduce it. If its a common board or chipset we can probably get it and work on the issue. The zeroed block showed up in 8KB boundaries in the instance we saw, which is asupicious since most OHCI controllers have a DMA limitation of 1 page crossing. I have a ppro with Intel OHCI which I haven't tested yet. On Sat, 27 Sep 2003, Dave Truesdell wrote: > -- Your message was: (from "Wesley Morgan") > On Fri, 26 Sep 2003, Brian Fundakowski Feldman wrote: > > > I can get fdisk to read the MBR, but when I try mdir, I get this trace back > > (of course, no crash dump because those haven't worked for me in a year): > > trap 0xc > > memcpy() > > ohci_softintr() > > usb_schedsoftintr() > > ohci_intr1() > > ohci_intr() > > ithread_loop() > > > > Anyone have any clued? I'll include my dmesg, of course. > > It was unbroken for a while, but has been broken for at least a month > (seem my earlier post about it). The umass driver has been a constant > source of frustation for me and suffers from constant breakage and > neglect. > > -- End of Message > > You may not want to blame the umass driver. I've been doing a little > experimenting trying to get a handle on what's going on. Luckily I have two > machines sitting side-by-side, one with OHCI and one with UHCI. Many of the > UMASS devices I have fail with 5.1-CURRENT on the OHCI machine but work just > fine on the UHCI system. > > Here's the note I sent as a followup to kern/54982: > I am encountering this problem as well. What I've seen so far is this: > > 1. The corruption does not occur with all UMASS devices. For example, I > see data corruption with a Creative Labs MUVO (128M) and NEXDISK (256M) > devices, but not with an Easydisc (128M) device. > > 2. I've only seen the corruption with OHCI based controllers. When I > connect the same device to a UHCI based machine, built from an identical > copy of the source tree, I see no corruption. > > 3. The pattern of corruption is decidely non-random. If you view the > file as a series of 4K blocks numbered 0 to N, the corruption I've seen > follows the following pattern: > (B == a zero filled 4k block) > > Original: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 ... > Corrupt: 0 3 2 B 4 7 6 B 8 11 10 B 12 15 14 B ... > > I can provide logs of a file copy done on both the OHCI and UHCI based > systems done with hw.usb.debug=3 hw.usb.uhci.debug=6 hw.usb.ohci.debug=6 > and hw.usb.umass.debug=4294901760 if you wish. They are far too long to > attach here. > > This test was last run on 5.1-CURRENT cvsup'd on Sep 17th 2003. > > I'm presently updating both machines to -CURRENT cvsup'd this afternoon. > > I haven't gotten to the point where I understand the interactions between > umass, ohci/uhci and cam well enough to even hazzard a guess about where the > corruption is occuring. > > > > > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: your mail
Please use subject lines. Thanks. On Mon, 29 Sep 2003, Tomi Vainio - Sun Finland wrote: > Dag-Erling Smørgrav writes: > > > > An NMI almost certainly indicates a hardware failure. > > > Lucas James writes: > > > > 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.) > > > We're already running this system with two power supplys. All old > stuff is using old power and 4 new disks were attached to new one. Well this might be the source of problems. I've expressed caution at doing this sorrt of thing before since getting the grounds equallized can be tricky. If the ground levels become unequalized, or worse you get some sort of ground loop going, you could damage your hardware, or cause Wierd Untraceable Problems. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: your mail
In message <[EMAIL PROTECTED]>, Doug White writes: >Well this might be the source of problems. I've expressed caution at >doing this sorrt of thing before since getting the grounds equallized can >be tricky. If the ground levels become unequalized, or worse you get some >sort of ground loop going, you could damage your hardware, or cause Wierd >Untraceable Problems. ... not to mention escape of magic smoke, and in truly worst case: permanent tax-exemption. -- 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: Status of SCHED_ULE?
Hi ! > I use the /dev/sysmouse and moused, not quite sure > why but that's how I've always used my mouse (PS2 or USB) with > FreeBSD. Could this have something to do with the mouse feeling > sloppy? Hmmm, I never used moused and always /dev/psm0 in X. Still experience the same thing. Cheers Peter ___ [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
On Mon, Sep 29, 2003 at 07:29:08AM +0200, Poul-Henning Kamp wrote: > 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. I'd say that for tun devices, the new symantics are probably good. We can worry about supporting interface cloning on them later. -- Brooks -- 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
if_em and ibm thinkpad T40
I have an IBM T40 that has an onboard Intel GigE card. When the em driver tries to probe it, I get "The EEPROM Checksum Is Not Valid". Adding a printf, I discover the checksum is 0x08b8 (not the 0xBABA that is documented in the headers). Anyone else seen any problems with this? I'd really rather not have to drag around a USB ethernet device. -gordon pgp0.pgp Description: PGP signature
Re: 5.2-RELEASE TODO
On Mon, 29 Sep 2003, Robert Watson wrote: > |-+---+-+| > | | | | Userland bits | > | | | | implemented, | > | KSE support for | In| Marcel | kernel bits not| > | alpha | progress. | Moolenaar | implemented. | > | | | | Required for | > | | | | 5.2-RELEASE. | You should probably remove Marcel from this item. This task needs another volunteer. -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 5.2-RELEASE TODO
On Mon, Sep 29, 2003 at 02:05:16PM -0400, Daniel Eischen wrote: > On Mon, 29 Sep 2003, Robert Watson wrote: > > > |-+---+-+| > > | | | | Userland bits | > > | | | | implemented, | > > | KSE support for | In| Marcel | kernel bits not| > > | alpha | progress. | Moolenaar | implemented. | > > | | | | Required for | > > | | | | 5.2-RELEASE. | > > You should probably remove Marcel from this item. This task needs > another volunteer. Recently Marcel noted to me he was planning to engage on this one. I have offered him help for testing. -- | / o / /_ _ [EMAIL PROTECTED] |/|/ / / /( (_) Bulte ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 5.2-RELEASE TODO
On Mon, 29 Sep 2003, Wilko Bulte wrote: > On Mon, Sep 29, 2003 at 02:05:16PM -0400, Daniel Eischen wrote: > > On Mon, 29 Sep 2003, Robert Watson wrote: > > > > > |-+---+-+| > > > | | | | Userland bits | > > > | | | | implemented, | > > > | KSE support for | In| Marcel | kernel bits not| > > > | alpha | progress. | Moolenaar | implemented. | > > > | | | | Required for | > > > | | | | 5.2-RELEASE. | > > > > You should probably remove Marcel from this item. This task needs > > another volunteer. > > Recently Marcel noted to me he was planning to engage on this one. I have > offered him help for testing. OK. This differs from what I heard from him just a couple of days ago. I'll just shut up and let things lie (as in rest) ;-) -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
SiL3112 SATA (RAID) Controller drives aren't working at all.
The drivers in 28.9.JPSNAP of current will allow you to install FreeBSD on a SATA disk connected to a Silicon Image 3112 SATA RAID controller but not much more. Shortly after booting, the system will start getting UDMA timeouts and basically just freezes. Furthermore, the disks connected to the controller will ALWAYS show up as individual disks in the setup, no matter if they are alone, in a stripe set or a real RAID 1 array. Seeing that this probably belongs in Soren's domain, is there any possibility to add some function to atacontrol to allow rebuilding without having hotswap on HPT/Promise chipsets? (I know the Windows drivers of both can do so, so imagine the feature has to be somewhere). ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Bluetooth patch
Hi Maksim,
> I have prepared Bluetooth mega patch for FreeBSD source tree. This patch
> updates FreeBSD sources to the most recent snapshot. The patch is quite
> extensive - it adds two new libraries (libbluetooth and libsdp) as well
> as puts some files into /etc/bluetooth and modifies quite a few other files.
> I also have modified Makefile's to add new libraries and usr.{s}bin/bluetooth
> to the build.
>
> I've sent it to Julian and Ruslan, but they do not have free time to look
> at it. If anyone wants to review the patch please do so and let me know if
> i missed/forget anything.
>
> The patch could be downloaded from
>
> http://www.geocities.com/m_evmenkin/patch/bluetooth20030914.diff.gz
I had a look at the patch and here is my comments. I haven't tried it
yet, but I did try your latest snapshot. I haven't looked at the man
page markup, someone more knowledgable can do that, or it can be
committed and then Ruslan can have a look at it when he gets time.
There are lots of $FreeBSD$ changes. In a lot of the files that is the only
change.
The additions in lib/Makefile, share/man/man5/Makefile should be sorted
alphabetically.
I think libbluetooth and libsdp should be added to share/mk/bsd.libnames.mk
and then the Makefiles should be modified to use ${LIBBLUETOOTH} and ${LIBSDP}
on the DPADD lines. /usr/lib/libbluetooth.a should not be hardcoded otherwise
buildworld won't work correctly.
The + after DPADD and LDADD should be removed. It should only be used when
a Makefile have more than one DPADD or LDADD line
There should not be '-L/usr/lib' on the LDADD line.
PS. Will Julian commit it when there was a review or are you looking
for a committer too?
John
--
John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ATAng regression in current
I had not tried ACPI for about 3 weeks due to my travel schedule. I saw a number of updates and thought I'd give it a spin. System: IBM T30 running CURRENT as of last Friday (9/26) System has a master on ata0 and no devices at all on ata1. System will no longer recover from suspend. (This is probably an ATAng issue, not an ACPI one.) System resumes with the following messages: pcib0: slot 29 INTA is routed to irq 11 pcib0: slot 29 INTB is routed to irq 11 pcib0: slot 29 INTC is routed to irq 11 pcib0: slot 31 INTB is routed to irq 11 pcib0: slot 31 INTB is routed to irq 11 pcib0: slot 31 INTB is routed to irq 11 pcib1: slot 0 INTA is routed to irq 11 usb0: cannot start usb1: cannot start usb2: cannot start pcib2:slot 0 INTA is routed to irq 11 pcib2:slot 0 INTB is routed to irq 11 pcib2:slot 2 INTA is routed to irq 11 pcib2:slot 8 INTA is routed to irq 11 ata0: resetting devices... usb0: host system error usb0: host controller process error usb0: host controller halted usb1: host system error usb1: host controller process error usb1: host controller halted usb2: host system error usb2: host controller process error usb2: host controller halted done ata1: resetting devices... dmesg, config, acpidump output and other stuff available on request. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Odd ACPI behavior
I recently noticed that, when I boot with ACPI on my IBM T30, I get errors trying to probe the BIOS disabled sio1. This does not happen under apm and happens twice(?) when booting with ACPI and happens even though I have the line 'hint.sio.1.disabled="1"' in /boot/device.hints. >From my dmesg: sio0: type 16550A sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled acpi_cmbat0: on acpi0 acpi_cmbat1: on acpi0 acpi_acad0: on acpi0 sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled Any idea why this is happening? It does not seem to be a serious issue, but it is very odd. acpidump output, full dmesg, config and whatever available on request. Thanks, -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: SiL3112 SATA (RAID) Controller drives aren't working at all.
It seems Gabriel Ambuehl wrote: > The drivers in 28.9.JPSNAP of current will allow you to install > FreeBSD on a SATA disk connected to a Silicon Image 3112 SATA RAID > controller but not much more. Shortly after booting, the system will > start getting UDMA timeouts and basically just freezes. Furthermore, > the disks connected to the controller will ALWAYS show up as > individual disks in the setup, no matter if they are alone, in a > stripe set or a real RAID 1 array. First off, there is ONLY support for Promise and HPT "soft RAID" in the ATA driver, other vendors products are *not* supported (yet). Second, there seem to be a problem with some sil3112 setups where timeouts and what not ruins the lunch, but so far I've not been able to reproduce.. > Seeing that this probably belongs in Soren's domain, is there any > possibility to add some function to atacontrol to allow rebuilding > without having hotswap on HPT/Promise chipsets? (I know the Windows > drivers of both can do so, so imagine the feature has to be > somewhere). On -current 'man atacontrol' -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 5.2-RELEASE TODO
On Mon, Sep 29, 2003 at 08:07:32PM +0200, Wilko Bulte wrote: > > > > You should probably remove Marcel from this item. This task needs > > another volunteer. > > Recently Marcel noted to me he was planning to engage on this one. I have > offered him help for testing. The deal is this (if you find your way between the parenthesis): I talked to Wilko prior to the DevSummit and told him that since it was on my plate (because I stupidly made some commits to get things rolling; which it did, but not much more than rolling on my plate :-) and support is almost finished (I looked at it this weekend and it appears that upcalls work, there's probably something wrong with the context save/restore code) and I needed to fix ia64 as which (already done) I likely would fix Alpha in one big swoop. At the DevSummit we failed to reach agreement that alpha should be dropped to a tier 2 platform, but we did acknowledge that alpha needs developers pronto. There it was also agreed that I would enter a holding pattern (which roughly boils down to me circling between home, work and Starbucks) until either someone fixes KSE or my weakness shows and I do it anyway (the fact that I looked at it this weekend means that I was pretty close to folding -- I made it to Starbucks just in time). I also mentioned recently (in the last couple of days) that we should worry more about sparc64 than alpha. Simply because I think alpha is on it's way down and should already be a tier 2 platform and sparc64 is still on its way up ... sort of. -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 5.2-RELEASE TODO
On Mon, Sep 29, 2003 at 12:19:30PM -0700, Marcel Moolenaar wrote: > On Mon, Sep 29, 2003 at 08:07:32PM +0200, Wilko Bulte wrote: > > > > > > You should probably remove Marcel from this item. This task needs > > > another volunteer. > > > > Recently Marcel noted to me he was planning to engage on this one. I have > > offered him help for testing. > > The deal is this (if you find your way between the parenthesis): > ... > At the DevSummit we failed to reach agreement that alpha should be > dropped to a tier 2 platform, but we did acknowledge that alpha needs > developers pronto. There it was also agreed that I would enter a > holding pattern (which roughly boils down to me circling between home, > work and Starbucks) until either someone fixes KSE or my weakness > shows and I do it anyway (the fact that I looked at it this weekend > means that I was pretty close to folding -- I made it to Starbucks > just in time). You get red hair from too much coffee anyway :-) :-) > I also mentioned recently (in the last couple of days) that we should > worry more about sparc64 than alpha. Simply because I think alpha is > on it's way down and should already be a tier 2 platform and sparc64 > is still on its way up ... sort of. In my book sparc64 is also with one foot in the grave. As is Sun itself. If we want to be future proof ia64 and amd64 are the only viable architectures. The rest are just interesting passtimes.. -- | / o / /_ _ [EMAIL PROTECTED] |/|/ / / /( (_) Bulte ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: SiL3112 SATA (RAID) Controller drives aren't working at all.
On Mon, Sep 29, 2003 at 09:13:48PM +0200, Soren Schmidt wrote: > First off, there is ONLY support for Promise and HPT "soft RAID" > in the ATA driver, other vendors products are *not* supported (yet). > > Second, there seem to be a problem with some sil3112 setups where > timeouts and what not ruins the lunch, but so far I've not been > able to reproduce.. I am still unable to use my SATA drive, it's probed incorrectly as I posted earlier. Reverting to the August 10th 00:00 UTC kernel fixes this problem, so I concluded that ATAng broke this. If it makes any difference, my model is a SiI3112 RAID controller, but I only have one drive and it probes as ad4... the situation doesn't improve any if I add "ataraid". But maybe ATAng doesn't take into account the difference between a "normal" and a "RAID" SiI 3112, if any? Here are my dmesg's again (Sep 18th, Aug 10th kernels): http://csociety.org/~will/dmesg.badATAng http://csociety.org/~will/dmesg.Aug10.preATAng The problem shown in the first dmesg still showed itself when I tried a new kernel on Sep 25th. Regards, -- wca ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ICH sound after suspend/resume
On Mon, 29 Sep 2003, Kevin Oberman wrote: > Re: kern/55395 > > I see a patch to ich.c back on the 15th to "Correctly reset ich[3-5] > sound cards on resume.", but I am still not able to properly use my > sound card after a resume because the card starts clocking at the wrong > rate, about 52K instead of the correct 48,000. > > There is nothing in the tying it to any PR, but it looks like it's > trying to do the "right thing" on resume. > > As before, the sysctl for the sampling rate has no effect. > > Any ideas what I might try? I'll take a look at this eventually. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Bluetooth patch
Hi John,
> > I have prepared Bluetooth mega patch for FreeBSD source tree. This patch
> > updates FreeBSD sources to the most recent snapshot.
[...]
> > The patch could be downloaded from
> >
> > http://www.geocities.com/m_evmenkin/patch/bluetooth20030914.diff.gz
>
> I had a look at the patch and here is my comments. I haven't tried it
> yet, but I did try your latest snapshot.
good, did it (snapshot) work for you?
> I haven't looked at the man
> page markup, someone more knowledgable can do that, or it can be
> committed and then Ruslan can have a look at it when he gets time.
i tried to follow original man page style. it is possible that i missed
few minor things, but in general i think it should be fine. my plan was
to double check everything after commit and deal with the issues.
> There are lots of $FreeBSD$ changes. In a lot of the files that is the only
> change.
i see, is that a problem? i can clean up the patch and remove these entries.
(frankly i thought CVS should take care of it).
> The additions in lib/Makefile, share/man/man5/Makefile should be sorted
> alphabetically.
sure, i assume i should sort entries in lib/Makefile for
.if ${MACHINE_ARCH} == "i386" section right?
> I think libbluetooth and libsdp should be added to share/mk/bsd.libnames.mk
> and then the Makefiles should be modified to use ${LIBBLUETOOTH} and
> ${LIBSDP}
> on the DPADD lines. /usr/lib/libbluetooth.a should not be hardcoded
> otherwise
> buildworld won't work correctly.
ok, i missed that one :) thanks!
> The + after DPADD and LDADD should be removed. It should only be used when
> a Makefile have more than one DPADD or LDADD line
>
> There should not be '-L/usr/lib' on the LDADD line.
got it.
so, i hope those are minor things. can they be resolved right after commit
is done? or i must fix them and submit revised patch?
> PS. Will Julian commit it when there was a review or are you looking
> for a committer too?
Julian and Ruslan are busy at the moment. M. Warner Losh has sent e-mail
to core@ and asked for commit bit for me. in the mean time i'd like to
commit this and resolve all issues in time for 5.2-RELEASE.
thanks,
max
__
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 5.2-RELEASE TODO
In the last episode (Sep 29), Wilko Bulte said: > On Mon, Sep 29, 2003 at 12:19:30PM -0700, Marcel Moolenaar wrote: > > I also mentioned recently (in the last couple of days) that we > > should worry more about sparc64 than alpha. Simply because I think > > alpha is on it's way down and should already be a tier 2 platform > > and sparc64 is still on its way up ... sort of. > > In my book sparc64 is also with one foot in the grave. As is Sun > itself. Fujitsu makes sparc-compatible CPUs, too, so it'll be harder to kill the entire architecture like HP did with the Alpha. -- Dan Nelson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: Odd ACPI behavior
On 29-Sep-2003 Kevin Oberman wrote: > I recently noticed that, when I boot with ACPI on my IBM T30, I get > errors trying to probe the BIOS disabled sio1. This does not happen > under apm and happens twice(?) when booting with ACPI and happens even > though I have the line 'hint.sio.1.disabled="1"' in /boot/device.hints. >>From my dmesg: > sio0: type 16550A > sio1: configured irq 3 not in bitmap of probed irqs 0 > sio1: port may not be enabled > acpi_cmbat0: on acpi0 > acpi_cmbat1: on acpi0 > acpi_acad0: on acpi0 > sio1: configured irq 3 not in bitmap of probed irqs 0 > sio1: port may not be enabled > > Any idea why this is happening? It does not seem to be a serious > issue, but it is very odd. > > acpidump output, full dmesg, config and whatever available on request. Do you kldload a module at some point during your boot? If so, that would explain the double probe. -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 5.2-RELEASE TODO
In message <[EMAIL PROTECTED]>, Dan Nelson writes: >> In my book sparc64 is also with one foot in the grave. As is Sun >> itself. > >Fujitsu makes sparc-compatible CPUs, too, so it'll be harder to kill >the entire architecture like HP did with the Alpha. Having at least on architecture with the other byte order helps keep our code honest. I also think that VM afflicted people tend to think that it is a good idea to have another model in order to keep MI separated properly from MD. Alpha has sort of outlived its role as our "token architecture", "pc98" doesn't qualify due to inbreeding, "amd64" doesn't qualify due to nepotism, "ia64" is not yet there. That leaves us only "sparc64" as candidate for that job. Therefore I would like to keep the sparc64 port alive, even at a pretty high cost in effort. -- 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]"
Fatal trap 12: ... while installing emulators/linux_base
Hello, I've tried to install emulators/linux_base on my FreeBSD 5.1-CURRENT (todays world) and got the following: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x3 fault code = supervisor read, page not present instuction pointer = 0x8:0xc04c1190 stack pointer = 0x10:0xe907e6d4 frame pointer = 0x10:0xe907e6d8 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= resume, IOPL = 0 current process = 1648 (rpm) kernel: type 12 trap, code=0 I've tried to install with GENERIC and my custom kernel - same problem ... vd ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Odd ACPI behavior
> Date: Mon, 29 Sep 2003 16:04:25 -0400 (EDT) > From: John Baldwin <[EMAIL PROTECTED]> > > > On 29-Sep-2003 Kevin Oberman wrote: > > I recently noticed that, when I boot with ACPI on my IBM T30, I get > > errors trying to probe the BIOS disabled sio1. This does not happen > > under apm and happens twice(?) when booting with ACPI and happens even > > though I have the line 'hint.sio.1.disabled="1"' in /boot/device.hints. > >>From my dmesg: > > sio0: type 16550A > > sio1: configured irq 3 not in bitmap of probed irqs 0 > > sio1: port may not be enabled > > acpi_cmbat0: on acpi0 > > acpi_cmbat1: on acpi0 > > acpi_acad0: on acpi0 > > sio1: configured irq 3 not in bitmap of probed irqs 0 > > sio1: port may not be enabled > > > > Any idea why this is happening? It does not seem to be a serious > > issue, but it is very odd. > > > > acpidump output, full dmesg, config and whatever available on request. > > Do you kldload a module at some point during your boot? If so, that > would explain the double probe. Yes, it would, but I am not loading any kernel modules except the slightly automatic loads of ACPI, itself and a few others which should not cause a probe: ntfs, linux, linprocfs, and daemon_saver. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [acpi-jp 2704] Re: Odd ACPI behavior
On Mon, 29 Sep 2003, Kevin Oberman wrote: > > Date: Mon, 29 Sep 2003 16:04:25 -0400 (EDT) > > From: John Baldwin <[EMAIL PROTECTED]> > > > > On 29-Sep-2003 Kevin Oberman wrote: > > > I recently noticed that, when I boot with ACPI on my IBM T30, I get > > > errors trying to probe the BIOS disabled sio1. This does not happen > > > under apm and happens twice(?) when booting with ACPI and happens even > > > though I have the line 'hint.sio.1.disabled="1"' in /boot/device.hints. > > >>From my dmesg: > > > sio0: type 16550A > > > sio1: configured irq 3 not in bitmap of probed irqs 0 > > > sio1: port may not be enabled > > > acpi_cmbat0: on acpi0 > > > acpi_cmbat1: on acpi0 > > > acpi_acad0: on acpi0 > > > sio1: configured irq 3 not in bitmap of probed irqs 0 > > > sio1: port may not be enabled > > > > Do you kldload a module at some point during your boot? If so, that > > would explain the double probe. > > Yes, it would, but I am not loading any kernel modules except the > slightly automatic loads of ACPI, itself and a few others which should > not cause a probe: ntfs, linux, linprocfs, and daemon_saver. ACPI attaches the bus twice. See sys/dev/acpica/acpi.c: /* * Scan all of the child devices we have created and let them probe/attach. */ ACPI_DEBUG_PRINT((ACPI_DB_OBJECTS, "first bus_generic_attach\n")); bus_generic_attach(bus); /* * Some of these children may have attached others as part of their attach * process (eg. the root PCI bus driver), so rescan. */ ACPI_DEBUG_PRINT((ACPI_DB_OBJECTS, "second bus_generic_attach\n")); bus_generic_attach(bus); -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [acpi-jp 2704] Re: Odd ACPI behavior
> Date: Mon, 29 Sep 2003 13:33:06 -0700 (PDT) > From: Nate Lawson <[EMAIL PROTECTED]> > Sender: [EMAIL PROTECTED] > > On Mon, 29 Sep 2003, Kevin Oberman wrote: > > > Date: Mon, 29 Sep 2003 16:04:25 -0400 (EDT) > > > From: John Baldwin <[EMAIL PROTECTED]> > > > > > > On 29-Sep-2003 Kevin Oberman wrote: > > > > I recently noticed that, when I boot with ACPI on my IBM T30, I get > > > > errors trying to probe the BIOS disabled sio1. This does not happen > > > > under apm and happens twice(?) when booting with ACPI and happens even > > > > though I have the line 'hint.sio.1.disabled="1"' in /boot/device.hints. > > > >>From my dmesg: > > > > sio0: type 16550A > > > > sio1: configured irq 3 not in bitmap of probed irqs 0 > > > > sio1: port may not be enabled > > > > acpi_cmbat0: on acpi0 > > > > acpi_cmbat1: on acpi0 > > > > acpi_acad0: on acpi0 > > > > sio1: configured irq 3 not in bitmap of probed irqs 0 > > > > sio1: port may not be enabled > > > > > > Do you kldload a module at some point during your boot? If so, that > > > would explain the double probe. > > > > Yes, it would, but I am not loading any kernel modules except the > > slightly automatic loads of ACPI, itself and a few others which should > > not cause a probe: ntfs, linux, linprocfs, and daemon_saver. > > ACPI attaches the bus twice. See sys/dev/acpica/acpi.c: > > /* > * Scan all of the child devices we have created and let them probe/attach. > */ > ACPI_DEBUG_PRINT((ACPI_DB_OBJECTS, "first bus_generic_attach\n")); > bus_generic_attach(bus); > > /* > * Some of these children may have attached others as part of their attach > * process (eg. the root PCI bus driver), so rescan. > */ > ACPI_DEBUG_PRINT((ACPI_DB_OBJECTS, "second bus_generic_attach\n")); > bus_generic_attach(bus); Thanks. That explains why I get the message twice, but why do I get it at all when the device is disabled in the device.hints file? -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Bluetooth patch
>
> > > I have prepared Bluetooth mega patch for FreeBSD source tree. This patch
> > > updates FreeBSD sources to the most recent snapshot.
>
> [...]
>
> > > The patch could be downloaded from
> > >
> > > http://www.geocities.com/m_evmenkin/patch/bluetooth20030914.diff.gz
> >
> > I had a look at the patch and here is my comments. I haven't tried it
> > yet, but I did try your latest snapshot.
>
> good, did it (snapshot) work for you?
Yes, I got a bluetooth ppp session going between 2 FreeBSD boxes with
usb-bluetooth devices.
> > I haven't looked at the man
> > page markup, someone more knowledgable can do that, or it can be
> > committed and then Ruslan can have a look at it when he gets time.
>
> i tried to follow original man page style. it is possible that i missed
> few minor things, but in general i think it should be fine. my plan was
> to double check everything after commit and deal with the issues.
That is ok.
> > There are lots of $FreeBSD$ changes. In a lot of the files that is the only
> > change.
>
> i see, is that a problem? i can clean up the patch and remove these entries.
> (frankly i thought CVS should take care of it).
I don't think it will break cvs, it might just cause some extra bloat.
Maybe just get rid of those parts of the patch where the only change
to the file is the $FreeBSD$ line?
> > The additions in lib/Makefile, share/man/man5/Makefile should be sorted
> > alphabetically.
>
> sure, i assume i should sort entries in lib/Makefile for
> .if ${MACHINE_ARCH} == "i386" section right?
Yes, that too, but inside such a block it should be alphabetical. SUBDIR
should also be alphabetical except for those mentioned in the comments at
the top of src/lib/Makefile.
> > I think libbluetooth and libsdp should be added to share/mk/bsd.libnames.mk
> > and then the Makefiles should be modified to use ${LIBBLUETOOTH} and
> > ${LIBSDP}
> > on the DPADD lines. /usr/lib/libbluetooth.a should not be hardcoded
> > otherwise
> > buildworld won't work correctly.
>
> ok, i missed that one :) thanks!
>
> > The + after DPADD and LDADD should be removed. It should only be used when
> > a Makefile have more than one DPADD or LDADD line
> >
> > There should not be '-L/usr/lib' on the LDADD line.
>
> got it.
>
> so, i hope those are minor things. can they be resolved right after commit
> is done? or i must fix them and submit revised patch?
I would prefer a patch with the makefile stuff fixed so that I can push
it through a make world and a make release before committing.
> > PS. Will Julian commit it when there was a review or are you looking
> > for a committer too?
>
> Julian and Ruslan are busy at the moment. M. Warner Losh has sent e-mail
> to core@ and asked for commit bit for me. in the mean time i'd like to
> commit this and resolve all issues in time for 5.2-RELEASE.
I can give it a go if no one else wants to do it.
John
--
John Hay -- [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: SiL3112 SATA (RAID) Controller drives aren't working at all.
Hey Will and Soren! :) On Sep 29, 2003, at 2:38 PM, Will Andrews wrote: On Mon, Sep 29, 2003 at 09:13:48PM +0200, Soren Schmidt wrote: First off, there is ONLY support for Promise and HPT "soft RAID" in the ATA driver, other vendors products are *not* supported (yet). Second, there seem to be a problem with some sil3112 setups where timeouts and what not ruins the lunch, but so far I've not been able to reproduce.. I am still unable to use my SATA drive, it's probed incorrectly as I posted earlier. Reverting to the August 10th 00:00 UTC kernel fixes this problem, so I concluded that ATAng broke this. I am not running a very recent CURRENT but I do have ATAng from a fairly early point and it works here. [I have the same chipset as Will SiI3112A RAID] If it makes any difference, my model is a SiI3112 RAID controller, but I only have one drive and it probes as ad4... the situation doesn't improve any if I add "ataraid". But maybe ATAng doesn't take into account the difference between a "normal" and a "RAID" SiI 3112, if any? Even Linux probes both disks even though I have but one. I don't use any RAID capabilities beyond enabling the hardware to access SATA. Here are my dmesg's again (Sep 18th, Aug 10th kernels): http://csociety.org/~will/dmesg.badATAng http://csociety.org/~will/dmesg.Aug10.preATAng The problem shown in the first dmesg still showed itself when I tried a new kernel on Sep 25th. I'd have to reboot and see how recent my FreeBSD stuff is... I have been rather distracted by the job which pays me salary :). Regards, -- wca ___ [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: SiL3112 SATA (RAID) Controller drives aren't working at all.
On Mon, Sep 29, 2003 at 04:05:11PM -0500, David Leimbach wrote: > I'd have to reboot and see how recent my FreeBSD stuff is... I have been > rather distracted by the job which pays me salary :). If you can do that, I'll check out a copy of the kernel from that day and try to narrow down when the SiI3112A/WD Raptor probe broke. Hopefully that will be of more use to Soren. Regards, -- wca ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Problems with geom_bde
Hi, inspired by the recent posting of the gbde tutorial I went out and set up an encrypted partition using geom_bde on my laptop. When trying to umount this partition the umount fails with: # umount /crypto umount: unmount of /crypto failed: Resource temporarily unavailable and the following message gets logged: fsync: giving up on dirty: 0xc456ec8c: tag devfs, type VCHR, usecount 5140, writecount 0, refcount 93, flags (VV_OBJBUF), lock type devfs: EXCL (count 1) by thread 0xc4240130 dev ad0s3a.bde This is with a fairly recent kernel, cvsupped a few hours ago: # uname -a FreeBSD tybalt 5.1-CURRENT FreeBSD 5.1-CURRENT #26: Mon Sep 29 22:18:26 CEST 2003 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/TYBALT i386 The kernel config is a standard GENERIC with some device drivers removed. geom_bde was loaded as a module. Please let me know if I can provide further information. Regards -Thorsten -- You know you've landed gear-up when it takes full power to taxi. ___ [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 Monday 29 September 2003 08:05, Jeff Roberson wrote: > On Sun, 28 Sep 2003, Arjan van Leeuwen wrote: [...] > > 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. I'm experiencing similar stuff with kde + libthr (kernel built with sources from 18/9). Aggelos ___ [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 Tue, 30 Sep 2003, Aggelos Economopoulos wrote: > On Monday 29 September 2003 08:05, Jeff Roberson wrote: > > On Sun, 28 Sep 2003, Arjan van Leeuwen wrote: > [...] > > > 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. > > I'm experiencing similar stuff with kde + libthr (kernel built with sources > from 18/9). > > Aggelos > Are you running seti, rc4, etc? Any programs that sit in the background and consume 100% of the cpu? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: procfs problem
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> > > JM>map02# strace -p 730
> > > JM>strace: open("/proc/...", ...): No such file or directory
> > > JM>trouble opening proc file
> >
> > > You must mount procfs.
> > >
> > > # fstab;
> > > proc /proc procfs rw 0 0
> >
> > The bi-weekly status messages have been claiming that all the common
> > debugging tools except for truss have been converted to work without
> > procfs, since procfs is now deprecated. Does that not include strace, or
> > is there something else wrong here?
>
> strace is not part of FreeBSD.
Oh - I didn't think that truss was either, which lead me to believe that
someone had gone through ports and fixed a bunch of them.
Is someone working on fixing the strace and truss ports yet? Are there
other popular ports that depend on procfs?
-Jason
--
Freud himself was a bit of a cold fish, and one cannot avoid the suspicion
that he was insufficiently fondled when he was an infant.
-- Ashley Montagu
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (FreeBSD)
Comment: See https://private.idealab.com/public/jason/jason.gpg
iD8DBQE/eLTxswXMWWtptckRAtTdAKCiiZ1ffDqyLx0ZdT8pKEGmv1LX/wCgrTbx
M3/ZMG8QAIivfTdyfm3zNWM=
=s77n
-END PGP SIGNATURE-
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: SiL3112 SATA (RAID) Controller drives aren't working at all.
On Sep 29, 2003, at 4:07 PM, Will Andrews wrote: On Mon, Sep 29, 2003 at 04:05:11PM -0500, David Leimbach wrote: I'd have to reboot and see how recent my FreeBSD stuff is... I have been rather distracted by the job which pays me salary :). If you can do that, I'll check out a copy of the kernel from that day and try to narrow down when the SiI3112A/WD Raptor probe broke. Hopefully that will be of more use to Soren. Ok... I built mine on Thu Sep 18 22:42:16 CDT 2003. I think that's post ATAng commit. Regards, -- wca ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: SiL3112 SATA (RAID) Controller drives aren't working at all.
On Mon, Sep 29, 2003 at 05:42:24PM -0500, David Leimbach wrote: > Ok... I built mine on Thu Sep 18 22:42:16 CDT 2003. > I think that's post ATAng commit. WTF?!?! My problem is for Sep 18 kernel and later. I'll have to try Sep 15 or something just to see... Regards, -- wca ___ [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 Tuesday 30 September 2003 01:12, Jeff Roberson wrote: > On Tue, 30 Sep 2003, Aggelos Economopoulos wrote: > > On Monday 29 September 2003 08:05, Jeff Roberson wrote: > > > On Sun, 28 Sep 2003, Arjan van Leeuwen wrote: > > > > [...] > > > > > > 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. > > > > I'm experiencing similar stuff with kde + libthr (kernel built with > > sources from 18/9). > > > > Aggelos > > Are you running seti, rc4, etc? Any programs that sit in the background > and consume 100% of the cpu? No. But interactive performance deteriorates instantly when compiling or linking two or more programs (of course I expect it to deteriorate, but the gui is _much_ more jerky with SCHED_ULE than with SCHED_4BSD). Let me know if I can help with any more info. Aggelos ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [acpi-jp 2706] Re: Odd ACPI behavior
On Mon, 29 Sep 2003, Kevin Oberman wrote: > > Date: Mon, 29 Sep 2003 13:33:06 -0700 (PDT) > > From: Nate Lawson <[EMAIL PROTECTED]> > > ACPI attaches the bus twice. See sys/dev/acpica/acpi.c: > > > > /* > > * Scan all of the child devices we have created and let them probe/attach. > > */ > > ACPI_DEBUG_PRINT((ACPI_DB_OBJECTS, "first bus_generic_attach\n")); > > bus_generic_attach(bus); > > > > /* > > * Some of these children may have attached others as part of their attach > > * process (eg. the root PCI bus driver), so rescan. > > */ > > ACPI_DEBUG_PRINT((ACPI_DB_OBJECTS, "second bus_generic_attach\n")); > > bus_generic_attach(bus); > > Thanks. That explains why I get the message twice, but why do I get it > at all when the device is disabled in the device.hints file? Dunno. That's probably an sio(4) problem. It does that on my laptop also. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: procfs problem
On Mon, Sep 29, 2003 at 03:40:49PM -0700, Jason Stone wrote: > Oh - I didn't think that truss was either, which lead me to believe that > someone had gone through ports and fixed a bunch of them. > whereis truss truss: /usr/bin/truss /usr/share/man/man1/truss.1.gz /usr/src/usr.bin/truss > Is someone working on fixing the strace and truss ports yet? It's not broken, you just need a non-default FreeBSD configuration to use it. > Are there other popular ports that depend on procfs? Surely there are other ports that do. Kris pgp0.pgp Description: PGP signature
Re: Bluetooth patch
In message: <[EMAIL PROTECTED]> John Hay <[EMAIL PROTECTED]> writes: : > Julian and Ruslan are busy at the moment. M. Warner Losh has sent e-mail : > to core@ and asked for commit bit for me. in the mean time i'd like to : > commit this and resolve all issues in time for 5.2-RELEASE. : : I can give it a go if no one else wants to do it. The core approval process for committers takes one week, so he should have his commit bit in plenty of time. However, if you'd like to help review the changes before/as they go into the tree, my feelings won't be hurt :-) Warner ___ [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 2003-09-30 02:07 +0300, Aggelos Economopoulos wrote: > On Tuesday 30 September 2003 01:12, Jeff Roberson wrote: > > On Tue, 30 Sep 2003, Aggelos Economopoulos wrote: > > > On Monday 29 September 2003 08:05, Jeff Roberson wrote: > > > > On Sun, 28 Sep 2003, Arjan van Leeuwen wrote: > > > > > > [...] > > > > > > > > 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. > > > I'm having the same experience, no gnome involved. > > > I'm experiencing similar stuff with kde + libthr (kernel built with > > > sources from 18/9). > > > > > > Aggelos > > > > Are you running seti, rc4, etc? Any programs that sit in the background > > and consume 100% of the cpu? > > No. But interactive performance deteriorates instantly when compiling or > linking two or more programs (of course I expect it to deteriorate, but the > gui is _much_ more jerky with SCHED_ULE than with SCHED_4BSD). Let me know if > I can help with any more info. > I second that. I'm not running anything heavy, background or not. Windowmaker, a few desktops, a bunch of aterms -- that's more or less all. The most easily noticeable pessimization is probably Firebird (or Mozilla if you prefer). Compile anything, and try opening or closing a few tabs, or navigating. It's rather painful. This is on a Thunderbird 1200 sporting 512MB RAM. It's not exactly fast by today's standards, but operation is much smoother under SCHED_4BSD. -- Munish Chopra ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
SCHED_ULE
There seems to have been some regression in the interactivity of SCHED_ULE since I was last measuring it. I'll send a follow up mail when I have found and fixed the issue. Thanks, Jeff ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Bluetooth patch
On Mon, Sep 29, 2003 at 05:49:08PM -0600, M. Warner Losh wrote: > In message: <[EMAIL PROTECTED]> > John Hay <[EMAIL PROTECTED]> writes: > : > Julian and Ruslan are busy at the moment. M. Warner Losh has sent e-mail > : > to core@ and asked for commit bit for me. in the mean time i'd like to > : > commit this and resolve all issues in time for 5.2-RELEASE. > : > : I can give it a go if no one else wants to do it. > > The core approval process for committers takes one week, so he should > have his commit bit in plenty of time. Hey, I didn't realise the process was that far already. My initial reaction was because it looked like nobody else reacted and I got tired of having to add the bluetooth snap everytime. :-) > However, if you'd like to help > review the changes before/as they go into the tree, my feelings won't > be hurt :-) If you need help time wise I'd be happy to help. John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
SiI 3112A doesn't probe, take two: found the commit that broke it
Hi, http://lists.freebsd.org/pipermail/cvs-src/2003-September/009918.html src/sys/dev/ata/ata-all.c, rev 1.188 src/sys/dev/ata/ata-lowlevel.c, rev 1.8 After an exhaustive binary search, I've found this is the commit that broke probing for my SATA disk. Merely reverting the change on the latest kernel doesn't compile, however. :-\ Hope this is more helpful, Soren... I'll just stick with the Sep 1 00:00 UTC kernel for now. If you have any patches you think will fix this problem feel free to ask me to test. Regards, -- wca ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Serial debug broken in recent -CURRENT?
On Mon, 29 Sep 2003, Greg 'groggy' Lehey wrote: > After building a new kernel, remote serial gdb no longer works. When > I issue a 'continue' command, I lose control of the system, but it > doesn't continue running. Has anybody else seen this? It works as well as it did a few months ago here. (Not very well compared with ddb. E.g., calling a function is usually fatal.) Bruce ___ [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)
Once again our vinum build failed. This time it could do over 90% of 14 hours of work and we didn't got a panic just a "hang". Only we could do while system was printing ata error messages was to press reset button. Difference to earlier situation is that we put back old 3c905 xl-card and removed 4 port dc-Znyx. At the same time we changed pci card positions. Do you still think this has nothing do ata kernel code? Tomppa login: ad6: WARNING - WRITE_DMA recovered from missing interrupt ad6: WARNING - WRITE_DMA recovered from missing interrupt ad6: WARNING - WRITE_DMA recovered from missing interrupt ad4: WARNING - WRITE_DMA recovered from missing interrupt ata2: spurious interrupt - status=0x51 error=0x84 reason=0x01 ad6: WARNING - WRITE_DMA recovered from missing interrupt ata2: spurious interrupt - status=0x51 error=0x84 reason=0x01 ata2: spurious interrupt - status=0x51 error=0x84 reason=0x01 ata2: spurious interrupt - status=0x51 error=0x84 reason=0x01 ata2: spurious interrupt - status=0x51 error=0x84 reason=0x01 ata2: spurious interrupt - status=0x51 error=0x84 reason=0x01 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
