Re: (LONG) ATA Benchmark: 5.x Reads Slower than Writes
On Fri, 8 Apr 2005, Danny Howard wrote: > I don't have the time and hardware to do very scientific tests, but I > have been able to run a series of benchmarks using bonnie++ on some > systems I have available to me. The ATA-based gmirror performs > extremely well, compared to a few Adaptec RAIDs that we have, EXCEPT > that the sequential and random reads are MUCH SLOWER than the hardware > solution, and even *slower than the preceding write operations*. This > is counter-intuitive, especially since RAID1 implies slowed writes and > faster reads. I tried the benchmark on my workstation (single 2.5" IDE > in a laptop) and got comparable write-faster-than-read results. > The raw data can be viewed at > http://dannyman.toldme.com/scratch/benchmarks/ Could you place the 'dmesg' output for each system in this directory? The output here is marginally useful since it shows the bonnie command line. However, 100MB as the test filesize is really small unless the systems have 64MB of RAM though -- otherwise you're testing how well FreeBSD manages memory (or how much crap the systems are running when you run this test). For recent I/O tests I was doing with iozone I was using 10GB filesizes. This blows out the cache on just about everything. > Unfortunately, my hardware RAIDs are on FreeBSD 4, and gmirror is on 5. > My hardware RAIDs are on dual CPU systems, with 2G RAM, and my gmirror > is on a single hyperthreaded CPU with 512M. Yes, sorry, not especially > scientific. Maybe the changes in FreeBSD make a big difference? Maybe > RAM makes a big difference? Yes, lots. Both 4.x vs. 5.x and RAM :) > Sequential Read > laptop 2.5" ATA: avg 76/s # SLOWER than write! > gmirror ATA RAID1: avg 251/s # SLOWER than write! > Adaptec SCSI RAID1: avg 7862/s > Adaptec SCSI RAID10: avg 7618/s I'd be really careful here... that is # of files read per second after the create, and as pointed out before, SoftUpdates usually gets you a big win until it has to flush the directories out then things suffer during the actual flush op since the disk gets hammered. Lots of free memory to use for the directory cache helps. The disk cache on the RAID controller is buying you even more. From your results you were getting 9ms latency which is spot-on so I think you are simply misinterpreting your results here. File creation tests are usually more for filesystem-specific benchmarking than for throughput benchmarking. I'd suggest something more like iozone for throughput testing. If the volumes have nothing on them you care about then rawio can also be instructive. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 5.4-PRERELEASE usb audio problem
On Sat, 2 Apr 2005, Christian Laursen wrote: > When I plug in my Logitech USB headset I get the following: > > uaudio0: Logitech Logitech USB Headset, rev 1.10/1.13, addr 2 > uaudio_add_selector: NOT IMPLEMENTED > uaudio0: audio rev 1.00 > pcm1: on uaudio0 > pcm1: chn_init(pcm1:play:0) failed: err = 19 > pcm1: pcm_chn_create(ua_chan, 1, 0xc1974780) failed > uhid0: Logitech Logitech USB Headset, rev 1.10/1.13, addr 2, iclass 1/1 > > With 5.3 and earlier it used to at least work for playback but now > it seems to be completely broken. > > I saw a lot of commits to uaudio, including recording support. Does > something need to be merged from -CURRENT for it to work properly? My analysis of the -CURRENT code indicates that there is missing functionality to implement this USB audio device. It requires synchronization to be run over a separate endpoint and the code to do that does not exist. The checks protected by #ifndef UAUDIO_MULTIPLE_ENDPOINTS is where you need to implement the functionality. The USB specs are completely open, but I don't know if sufficient support functions exist yet for performing the scheduling necessary to manage these types of endpoints. It may have worked before since input AudioStreaming interfaces were simply ignored, but now there is code to deal with input from stand-alone synchronous pipes and it rejects other configs due to the unimplemented code. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Error reading CD on 5.4 RC1
- Original Message - From: "Ken Menzel" <[EMAIL PROTECTED]> To: Sent: Friday, April 08, 2005 11:49 AM Subject: Error reading CD on 5.4 RC1 I am not sure this is directly related to 5.4 RC1 any suggestions are appreciated. acd0: FAILURE - READ_BIG HARDWARE ERROR asc=0x08 ascq=0x03 error=0 acd0: TIMEOUT - READ_BIG retrying (2 retries left) Notes on weird stuff: 1) Does not seem to happen until I install my Adaptec SCSI RAID 2230S. Don't know why. 2) I need to use 5.4 to get support for 2230S without patching. 3) cpio hangs at this error. IE: during install I get a hang or running sysinstall to install ports etc. 4) acd0: DVDROM at ata0-master UDMA33, previous 2 systems I setup used a CD drive with no problems (May be related to Teac DVD?) Please ignore this as the TODO list has the fix marked pending. I set hw.ata.atapi_dma=0 in /boot/loader.conf I don't know how to do this from an install CD, but I got far enough to boot the system and set this value. Sorry for the noise, how the default is changed before 5.4 release. Ken ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/79035: gvinum unable to create a striped set of mirrored sets/plexes
On Sun, 2005-03-20 at 15:51 +1030, Greg 'groggy' Lehey wrote:
> On Saturday, 19 March 2005 at 23:43:00 -0500, Sven Willenberger wrote:
> > Greg 'groggy' Lehey presumably uttered the following on 03/19/05 22:11:
> >> On Sunday, 20 March 2005 at 2:04:34 +, Sven Willenberger wrote:
> >>
> >>> Under the current implementation of gvinum it is possible to create
> >>> a mirrored set of striped plexes but not a striped set of mirrored
> >>> plexes. For purposes of resiliency the latter configuration is
> >>> preferred as illustrated by the following example:
> >>>
> >>> Use 6 disks to create one of 2 different scenarios.
> >>>
> >>> 1) Using the current abilities of gvinum create 2 striped sets using
> >>> 3 disks each: A1 A2 A3 and B1 B2 B3 then create a mirror of those 2
> >>> sets such that A(123) mirrors B(123). In this situation if any drive
> >>> in Set A fails, one still has a working set with Set B. If any drive
> >>> now fails in Set B, the system is shot.
> >>
> >> No, this is not correct. The plex ("set") only fails when all drives
> >> in it fail.
> >
> > I hope the following diagrams better illustrate what I was trying to
> > point out. Data striped across all the A's and that is mirrored to the B
> > Stripes:
> >
> > ...
> >
> > If A1 fails, then the A Stripe set cannot function (much like in Raid 0,
> > one disk fails the set) meaning that B now is the array:
>
> No, this is not correct.
>
> >>> Thus the striping of mirrors (rather than a mirror of striped sets)
> >>> is a more resilient and fault-tolerant setup of a multi-disk array.
> >>
> >> No, you're misunderstanding the current implementation.
> >
> > Perhaps I am ... but unless gvinum somehow reconstructs a 3 disk stripe
> > into a 2 disk stripe in the event one disk fails, I am now sure how.
>
> Well, you have the source code. It's not quite the way you look at
> it. It doesn't have stripes: it has plexes. And they can be
> incomplete. If a read to a plex hits a "hole", it automatically
> retries via (possibly all) the other plexes. Only when all plexes
> have a hole in the same place does the transfer fail.
>
> You might like to (re)read http://www.vinumvm.org/vinum/intro.html.
>
I was really hoping that the "holes in the plex" functioning was going
to work but my tests have shown otherwise. I created a gvinum array
consisting of (A striped B) mirror (C striped D) which is the only such
mirror/stripe combination allowed by gvinum for four drives. We have:
_
| A B |__
|___| |
|Mirror
_ |
| C D |--|
|___|
Based on what the "plex hole" theory states, Drive A and Drive D could
both fail and the system would read through the holes and pick up data
from B and C (or the converse if B and C failed), functionally
equivalent to a stripe of mirrors. To fail a drive I rebooted
single-user, dd dev/zero to the beginning of the disk and then fdisk.
drive d device /dev/da4s1h
drive c device /dev/da3s1h
drive b device /dev/da2s1h
drive a device /dev/da1s1h
volume home
plex name home.p1 org striped 960s vol home
plex name home.p0 org striped 960s vol home
sd name home.p1.s1 drive d len 71681280s driveoffset 265s plex home.p1
plexoffset 960s
sd name home.p1.s0 drive c len 71681280s driveoffset 265s plex home.p1
plexoffset 0s
sd name home.p0.s1 drive b len 71681280s driveoffset 265s plex home.p0
plexoffset 960s
sd name home.p0.s0 drive a len 71681280s driveoffset 265s plex home.p0
plexoffset 0s
In my case:Fail B Fail B and C
A = /dev/da1s1h up up
B = /dev/da2s1h downdown
C = /dev/da3s1h up down
D = /dev/da4s1h up up
1 Volume
V home2 up down (!)
2 Plexes
P home.p0 (A and B) downdown
P home.p1 (C and D) up down
4 Subdisks
S home.p0.s0 (A) up up
S home.p0.s1 (B) downdown
S home.p1.s0 (C) up down
S home p1.s1 (D) up up
Based on this failing the one drive did in fact fail the plex (home.p0).
Although at that point I realized that failing either drive on the other
plex would also fail that plex and also the volume, I went ahead and
failed drive C also. The result was a failed volume.
With the failed B drive, once I bsdlabeled the disk to include the vinum
slice, then I got the message that the the plex was now stale (instead
of down). A simple gvinum start home2 changed the state to degraded the
the system rebuilt the array. When both drives failed I had to work a
bit of a kludge in. I gvinum setstate -f up home.p1.s0, then gvinum
start home.p0. At that point the system rebuilt itself and it would
appear the data is intact .. I have not completely tested or verified
that last statement however.
In essence although my feature request to have the ability to create a
striped set of mirrors was going to be hopefully supplanted by the
functional equivalent via the "plex hole" system, it did not come to
fruition. So please note this as either a re-
Re: (LONG) ATA Benchmark: 5.x Reads Slower than Writes
On April 8, 2005 04:41 pm, Danny Howard wrote: > Hello, > > BACKGROUND > > I need to purchase a new system for our developers, for use as a > Postgres database test server. Having a RAID, probably RAID1, is > desirable for performance and reliability. I have recently set up a > system with a gmirror-based software RAID1 on a pair of 250GB ATA > drives. I would like to stick with gmirror, because: > > - We save money on extra hardware. > - Since gmirror is part of FreeBSD, maintenance is a lot easier than > with a hardware solution. > > SUMMARY > > But before I go balls out, I should see how well it compares to hardware > RAID. So, I do some benchmarks with bonnie++. Since this simulates > create, write and read on thousands of random files, this sounds like a > good approximation of what Postgres does. :) > > I don't have the time and hardware to do very scientific tests, but I > have been able to run a series of benchmarks using bonnie++ on some > systems I have available to me. The ATA-based gmirror performs > extremely well, compared to a few Adaptec RAIDs that we have, EXCEPT > that the sequential and random reads are MUCH SLOWER than the hardware > solution, and even *slower than the preceding write operations*. This > is counter-intuitive, especially since RAID1 implies slowed writes and > faster reads. I tried the benchmark on my workstation (single 2.5" IDE > in a laptop) and got comparable write-faster-than-read results. May I suggest that you turn softupdates off and sync on for the filesystems you are testing. If you don't you are not really testing the hardware. You are testing the FreeBSD disk caching system in the kernel. > DATA > > I was able to make use of the following test systems. I ran tests in > multi-user, but tried to favor times when there wasn't much background > activity: > > mito: (lone 2.5" ATA) > 5.4-PRERELEASE > CPU: Intel(R) Pentium(R) M processor 1.50GHz (1495.16-MHz 686-class CPU) > atapci0: > ata0: channel #0 on atapci0 > ata1: channel #1 on atapci0 > ad0: 28615MB [58140/16/63] at ata0-master > UDMA100 > > amun: (gmirror RAID1 2 x WD250GB High Intensity) > FreeBSD 5.3-RELEASE > CPU: Intel(R) Xeon(TM) CPU 2.80GHz (2799.22-MHz 686-class CPU) > atapci0: > ata2: channel #0 on atapci0 > ata3: channel #1 on atapci0 > ad4: 238475MB [484521/16/63] at > ata2-master SATA150 > ad6: 238475MB [484521/16/63] at > ata3-master SATA150 > atapci1: > acd0: CDROM at ata1-master UDMA33 > > janus: (Adaptec RAID1 2 x 72G 10,000 RPM SCSI) > FreeBSD 4.10-STABLE > CPU: Intel(R) Xeon(TM) CPU 2.40GHz (2399.33-MHz 686-class CPU) [DUAL] > aac0: mem 0xf800-0xfbff irq 16 at > device 1.0 on pci2 > aac0: i960RX 100MHz, 48MB cache memory, optional battery present > aac0: Kernel 4.0-0, Build 6011, S/N baec64 > aac0: Supported > Options=1f7eOND,SGMAP64,ALARM,NONDASD> aacd0: on aac0 > aacd0: 69998MB (143357184 sectors) > > db2: (Adaptec RAID10 4 x 36G 15,000 RPM SCSI) > FreeBSD 4.8-STABLE > CPU: Intel(R) Xeon(TM) CPU 3.06GHz (3065.81-MHz 686-class CPU) [DUAL] > aac0: mem 0xf800-0xfbff irq 18 at > device 2.0 on pci5 > aac0: i960RX 100MHz, 48MB cache memory, optional battery present > aac0: Kernel 4.0-0, Build 6008, S/N b97ce8 > aac0: Supported > Options=1f7eOND,SGMAP64,ALARM,NONDASD> aacp0: on aac0 > > The raw data can be viewed at > http://dannyman.toldme.com/scratch/benchmarks/ > > ANALYSIS > > Unfortunately, my hardware RAIDs are on FreeBSD 4, and gmirror is on 5. > My hardware RAIDs are on dual CPU systems, with 2G RAM, and my gmirror > is on a single hyperthreaded CPU with 512M. Yes, sorry, not especially > scientific. Maybe the changes in FreeBSD make a big difference? Maybe > RAM makes a big difference? > > The first results show a serious advantage for the gmirror setup: > > Sequential output (char) > gmirror ATA RAID1: avg 320K/s > Adaptec SCSI RAID1: avg 222K/s > Adaptec SCSI RAID10: avg 202K/s > > Sequential input (char) > gmirror ATA RAID1: avg 617K/s > Adaptec SCSI RAID1: avg 345K/s > Adaptec SCSI RAID10: avg 336K/s > > Sequential Output (block) > gmirror ATA RAID1: avg 37893K/s > Adaptec SCSI RAID1: avg 13829K/s > Adaptec SCSI RAID10: avg 40440K/s > > The gmirror sees slightly poorer performance in random seeks: > > Rndom Seeks > gmirror ATA RAID1: avg 4144/s > Adaptec SCSI RAID1: avg 5428/s > Adaptec SCSI RAID10: avg 13302/s > > That all sounds great if I was streaming video, but I want to run a > database, opening and closing, reading, writing, and rewriting several > small files. This is where things seem to go rotten. > > We see the ATA performance go to heck on the File Create tests: > > Sequential Create > laptop 2.5" ATA: avg 101/s > gmirror ATA RAID1: avg 365/s > Adaptec SCSI RAID1: avg 160/s > Adaptec SCSI RAID10: avg 412/s > > Sequential Read > laptop 2.5" ATA: avg 76/s # SLOWER than write! > gmirror ATA RAID1: avg 251/s # SLOWER than write! > Adaptec SCSI RAID1: avg 7862/s > Adaptec SCSI RAID1
(LONG) ATA Benchmark: 5.x Reads Slower than Writes
Hello, BACKGROUND I need to purchase a new system for our developers, for use as a Postgres database test server. Having a RAID, probably RAID1, is desirable for performance and reliability. I have recently set up a system with a gmirror-based software RAID1 on a pair of 250GB ATA drives. I would like to stick with gmirror, because: - We save money on extra hardware. - Since gmirror is part of FreeBSD, maintenance is a lot easier than with a hardware solution. SUMMARY But before I go balls out, I should see how well it compares to hardware RAID. So, I do some benchmarks with bonnie++. Since this simulates create, write and read on thousands of random files, this sounds like a good approximation of what Postgres does. :) I don't have the time and hardware to do very scientific tests, but I have been able to run a series of benchmarks using bonnie++ on some systems I have available to me. The ATA-based gmirror performs extremely well, compared to a few Adaptec RAIDs that we have, EXCEPT that the sequential and random reads are MUCH SLOWER than the hardware solution, and even *slower than the preceding write operations*. This is counter-intuitive, especially since RAID1 implies slowed writes and faster reads. I tried the benchmark on my workstation (single 2.5" IDE in a laptop) and got comparable write-faster-than-read results. DATA I was able to make use of the following test systems. I ran tests in multi-user, but tried to favor times when there wasn't much background activity: mito: (lone 2.5" ATA) 5.4-PRERELEASE CPU: Intel(R) Pentium(R) M processor 1.50GHz (1495.16-MHz 686-class CPU) atapci0: ata0: channel #0 on atapci0 ata1: channel #1 on atapci0 ad0: 28615MB [58140/16/63] at ata0-master UDMA100 amun: (gmirror RAID1 2 x WD250GB High Intensity) FreeBSD 5.3-RELEASE CPU: Intel(R) Xeon(TM) CPU 2.80GHz (2799.22-MHz 686-class CPU) atapci0: ata2: channel #0 on atapci0 ata3: channel #1 on atapci0 ad4: 238475MB [484521/16/63] at ata2-master SATA150 ad6: 238475MB [484521/16/63] at ata3-master SATA150 atapci1: acd0: CDROM at ata1-master UDMA33 janus: (Adaptec RAID1 2 x 72G 10,000 RPM SCSI) FreeBSD 4.10-STABLE CPU: Intel(R) Xeon(TM) CPU 2.40GHz (2399.33-MHz 686-class CPU) [DUAL] aac0: mem 0xf800-0xfbff irq 16 at device 1.0 on pci2 aac0: i960RX 100MHz, 48MB cache memory, optional battery present aac0: Kernel 4.0-0, Build 6011, S/N baec64 aac0: Supported Options=1f7e aacd0: on aac0 aacd0: 69998MB (143357184 sectors) db2: (Adaptec RAID10 4 x 36G 15,000 RPM SCSI) FreeBSD 4.8-STABLE CPU: Intel(R) Xeon(TM) CPU 3.06GHz (3065.81-MHz 686-class CPU) [DUAL] aac0: mem 0xf800-0xfbff irq 18 at device 2.0 on pci5 aac0: i960RX 100MHz, 48MB cache memory, optional battery present aac0: Kernel 4.0-0, Build 6008, S/N b97ce8 aac0: Supported Options=1f7e aacp0: on aac0 The raw data can be viewed at http://dannyman.toldme.com/scratch/benchmarks/ ANALYSIS Unfortunately, my hardware RAIDs are on FreeBSD 4, and gmirror is on 5. My hardware RAIDs are on dual CPU systems, with 2G RAM, and my gmirror is on a single hyperthreaded CPU with 512M. Yes, sorry, not especially scientific. Maybe the changes in FreeBSD make a big difference? Maybe RAM makes a big difference? The first results show a serious advantage for the gmirror setup: Sequential output (char) gmirror ATA RAID1: avg 320K/s Adaptec SCSI RAID1: avg 222K/s Adaptec SCSI RAID10: avg 202K/s Sequential input (char) gmirror ATA RAID1: avg 617K/s Adaptec SCSI RAID1: avg 345K/s Adaptec SCSI RAID10: avg 336K/s Sequential Output (block) gmirror ATA RAID1: avg 37893K/s Adaptec SCSI RAID1: avg 13829K/s Adaptec SCSI RAID10: avg 40440K/s The gmirror sees slightly poorer performance in random seeks: Rndom Seeks gmirror ATA RAID1: avg 4144/s Adaptec SCSI RAID1: avg 5428/s Adaptec SCSI RAID10: avg 13302/s That all sounds great if I was streaming video, but I want to run a database, opening and closing, reading, writing, and rewriting several small files. This is where things seem to go rotten. We see the ATA performance go to heck on the File Create tests: Sequential Create laptop 2.5" ATA: avg 101/s gmirror ATA RAID1: avg 365/s Adaptec SCSI RAID1: avg 160/s Adaptec SCSI RAID10: avg 412/s Sequential Read laptop 2.5" ATA: avg 76/s # SLOWER than write! gmirror ATA RAID1: avg 251/s # SLOWER than write! Adaptec SCSI RAID1: avg 7862/s Adaptec SCSI RAID10: avg 7618/s Random Create laptop 2.5" ATA: avg 124/s gmirror ATA RAID1: avg 354/s Adaptec SCSI RAID1: avg 155/s Adaptec SCSI RAID10: avg 504/s Random Read laptop 2.5" ATA: avg 57/s # SLOWER than write! gmirror ATA RAID1: avg 144/s # SLOWER than write! Adaptec SCSI RAID1: avg 7655/s Adaptec SCSI RAID10: avg 7413/s CONFUSION Now, I could explain poor read performance by: - Less RAM == Less buffer - Bigger Disks == Slower Seeks - Less CPU == ??? I DO have a 4.8-STABLE with a single IDE disk, no Soft Updates, and faster read than write: Version 1.93c ---
Re: Problems with AMD64 and 8 GB RAM?
David O'Brien wrote: On Tue, Apr 05, 2005 at 09:33:05AM +0200, Willem Jan Withagen wrote: I'm sorry to come into this discussion after 58 messages, but this board has been extensively discussed about 1 year ago, because it gave me trouble to no end (even with 2Gb). One of the early amd64 developers (not David or Scott) had the same board but could not get it stable under amd64 (i386 was fine with 2Gb). He tossed it, and suggested me to do the same. Hogwash. It was Peter Wemm and he was talking about the Asus SK8N, not the MSI K8T Master2-FAR. Not true unfortunatley I cannot seem to find the old mails on this. Probably got lost when upgrading my WinBox. But I'm very shure about this, why else would I burn a nice board and get me an expensive new one??? It is still somewhere in my storage I had several people look at my kerneldumps. (I even needed to fix a small bug for that in doadump().) Nobody seemed to be able to really explain what was wrong, and everything magically went away when I bought the Tyan board. So please don't tell me I was smoking something illegal. --WjW ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Problems with AMD64 and 8 GB RAM?
On Tue, Apr 05, 2005 at 09:33:05AM +0200, Willem Jan Withagen wrote: > I'm sorry to come into this discussion after 58 messages, but this board > has been extensively discussed about 1 year ago, because it gave me trouble > to no end (even with 2Gb). One of the early amd64 developers (not David or > Scott) had the same board but could not get it stable under amd64 (i386 was > fine with 2Gb). He tossed it, and suggested me to do the same. Hogwash. It was Peter Wemm and he was talking about the Asus SK8N, not the MSI K8T Master2-FAR. -- -- David ([EMAIL PROTECTED]) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Problems with AMD64 and 8 GB RAM? (solved)
On Tue, Apr 05, 2005 at 10:09:11AM +0930, Greg 'groggy' Lehey wrote: > The moral of the story is, I suppose, "don't buy the MSI K8T > Master2-FAR". I was warned about the motherboard before I bought it, WHY?? There is nothing wrong with that motherboard -- I have three of them. You are at fault for trying to treat a consumer desktop 2P mobo as a high-end server one. People do not run 2GB DIMM's in an MSI K8T Master2-FAR. If you want >4GB RAM get an eATX 4+4 DIMM configuration motherboard from Tyan or Iwill. The MSI K8T Master2-FAR works fine with 1GB DIMM's. Where on MSI's website did they state 2GB double-stacked DIMM's were supported? -- -- David ([EMAIL PROTECTED]) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 5.3 STABLE to 5.4-PRERELEASE
On Fri, Apr 01, 2005 at 09:59:05AM -0500, Irina wrote: > #cvsup -g /etc/cvsupfile > #make buildworld > #make -DALWAYS_CHECK_MAKE buildkernel KERNCONF=INET > #make -DALWAYS_CHECK_MAKE installkernel KERNCONF=INET > #make installworld > #reboot You missed the 'mergemaster' step. -ip -- When you do not know what you are going, do it neatly. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 5.4-STABLE panic
On Fri, 8 Apr 2005, Doug White wrote:
On Fri, 8 Apr 2005, Rene Ladan wrote:
has anyone seen this panic yet? It appears to be LOR-related :
This is a tough one since it occured while ddb was active. How did you
cause this?
This occurs because the low level syscons output routines incorrectly call
into KQ while in the debugger. I was sure I had fixed this, but maybe
it's fixed only in -CURRENT. If that's the case, it needs to be MFC'd --
not because it's a source of stability problems when running normally, but
because it makes debugging other bugs harder. In this case, the real bug
is up in the trap entries.
Looking at my local CVS checkout, I see that I actually didn't commit the
fix to HEAD either :-(. The patch is attached below, and is largely
untested.
Robert N M Watson
file=0xc05f619e "/usr/src/sys/kern/kern_event.c", line=1453)
at /usr/src/sys/kern/subr_witness.c:709
lock_list = (struct lock_list_entry **) 0xf00
lle = (struct lock_list_entry *) 0x20
lock1 = (struct lock_instance *) 0xc13df000
lock2 = (struct lock_instance *) 0x0
class = (struct lock_class *) 0xc062045c
w = (struct witness *) 0xc0648808
w1 = (struct witness *) 0xc0686b28
td = (struct thread *) 0xc13df000
---Type to continue, or q to quit---
i = -1067755093
j = -910530880
__func__ = "witness_checkorder"
#4 0xc048a5fa in _mtx_lock_flags (m=0xc1580110, opts=0,
file=0xc05f619e "/usr/src/sys/kern/kern_event.c", line=1453)
at /usr/src/sys/kern/kern_mutex.c:271
No locals.
#5 0xc0476d25 in knote (list=0xc1580098, hint=0, islocked=0)
at /usr/src/sys/kern/kern_event.c:1453
kq = (struct kqueue *) 0xc1580038
kn = (struct knote *) 0xc158
#6 0xc04c934e in ttwwakeup (tp=0xc158) at /usr/src/sys/kern/tty.c:2394
No locals.
#7 0xc05ba441 in scstart (tp=0xc158)
at /usr/src/sys/dev/syscons/syscons.c:1369
rbp = (struct clist *) 0xc1580038
len = 0
buf = "\fziÁ\200\a\000\000\000p\000\000\000ziÁlgºÉb`[À\fziÁ\200\a\000\000
\000\000\000\000p\000\000BK\000
\\gºÉ:z[ÀÀ\235hÀ\fziÁ\000ziÁ\000\a\000\000\224gºÉ\225a[À\000ziÁ\200\a\000\000
\000\000\000\000\a\000\000\000\000\000\000\000ziÁ\000ziÁÀ\235hÀÿÿgºÉ\016Â[À\000ziÁ\200\a\000\000\000\000\000"
scp = (scr_stat *) 0xc1697a00
#8 0xc05bd825 in scgetc (sc=0xc0689dc0, flags=3)
at /usr/src/sys/dev/syscons/syscons.c:3211
---Type to continue, or q to quit---
scp = (scr_stat *) 0xc1697a00
tp = (struct tty *) 0x0
c = 6
this_scr = -910530592
f = 0
i = 0
#9 0xc05ba899 in sccngetch (flags=2)
at /usr/src/sys/dev/syscons/syscons.c:1555
fkey = {str = "\033[A", '\0' , len = 3 '\003'}
fkeycp = 3
scp = (scr_stat *) 0xc1697a00
p = (u_char *) 0x0
cur_mode = 1
c = -1067204928
#10 0xc05ba6e2 in sccncheckc (cd=0xc0634480)
at /usr/src/sys/dev/syscons/syscons.c:1478
No locals.
#11 0xc04cbc98 in cncheckc () at /usr/src/sys/kern/tty_cons.c:567
cnd = (struct cn_device *) 0xc066c480
cn = (struct consdev *) 0x0
c = 0
#12 0xc04cbc45 in cngetc () at /usr/src/sys/kern/tty_cons.c:548
c = 0
#13 0xc042a535 in db_readline (lstart=0xc063bec0 "c\n", lsize=120)
---Type to continue, or q to quit---
at /usr/src/sys/ddb/db_input.c:324
No locals.
#14 0xc042a67a in db_read_line () at /usr/src/sys/ddb/db_lex.c:55
i = 0
#15 0xc0428d91 in db_command_loop () at /usr/src/sys/ddb/db_command.c:453
No locals.
#16 0xc042aef5 in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_main.c:221
jb = {{_jb = {-910530388, -910530416, -910530336, -1052905472, 0,
-1069371754, 0, 0, 0, 0, -910530336, -1068824416}}}
prev_jb = (void *) 0x0
bkpt = 0
#17 0xc04b0927 in kdb_trap (type=0, code=0, tf=0xc9ba6940)
at /usr/src/sys/kern/subr_kdb.c:418
handled = -910530240
#18 0xc05d8948 in trap (frame=
{tf_fs = -1051983848, tf_es = 16, tf_ds = -910557168, tf_edi = 9, tf_esi
= -1051954588, tf_ebp = -910530168, tf_isp = -910530196, tf_ebx = -1067007556,
tf_edx = 1, tf_ecx = -1056878592, tf_eax = 31, tf_trapno = 3, tf_err = 0,
tf_eip = -1068825056, tf_cs = 8, tf_eflags = 646, tf_esp = -1067470996, tf_ss =
-1067540423}) at /usr/src/sys/i386/i386/trap.c:576
td = (struct thread *) 0xc13df000
p = (struct proc *) 0xc13e61c4
sticks = 0
i = 0
---Type to continue, or q to quit---
ucode = 0
type = 3
code = 0
eva = 0
#19 0xc05c7d2a in calltrap () at /usr/src/sys/i386/i386/exception.s:140
No locals.
Index: syscons.c
===
RCS file: /home/ncvs/src/sys/dev/syscons/syscons.c,v
retrieving revision 1.433
diff -u -r1.433 syscons.c
--- syscons.c 27 Feb 2005 21:16:11 - 1.433
+++ syscons.c 4 Mar 2005 19:07:02 -
@@ -1457,9 +1457,11 @@
scp->status |= CURSOR_ENABLED;
Re: 5.4-STABLE panic
On Fri, 8 Apr 2005, Rene Ladan wrote:
> has anyone seen this panic yet? It appears to be LOR-related :
This is a tough one since it occured while ddb was active. How did you
cause this?
>
> [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so:
> Undefined symbol "ps_pglobal_lookup"]
> GNU gdb 6.1.1 [FreeBSD]
>
> #0 doadump () at pcpu.h:159
> 159 pcpu.h: No such file or directory.
> in pcpu.h
> (kgdb) bt f
> #0 doadump () at pcpu.h:159
> No locals.
> #1 0xc04944ea in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:410
> first_buf_printf = 1
> #2 0xc0494858 in panic (
> fmt=0xc05fc48f "blockable sleep lock (%s) %s @ %s:%d")
> at /usr/src/sys/kern/kern_shutdown.c:566
> td = (struct thread *) 0xc13df000
> bootopt = 256
> newpanic = 1
> ap = 0xc9ba6670 "ÃÅ`ÃÃÃ_Ã\236a_ÃÂ\005"
> buf = "blockable sleep lock (sleep mutex) tty @
> /usr/src/sys/kern/kern_event.c:1453", '\0'
> #3 0xc04bb0ae in witness_checkorder (lock=0xc1580110, flags=9,
> file=0xc05f619e "/usr/src/sys/kern/kern_event.c", line=1453)
> at /usr/src/sys/kern/subr_witness.c:709
> lock_list = (struct lock_list_entry **) 0xf00
> lle = (struct lock_list_entry *) 0x20
> lock1 = (struct lock_instance *) 0xc13df000
> lock2 = (struct lock_instance *) 0x0
> class = (struct lock_class *) 0xc062045c
> w = (struct witness *) 0xc0648808
> w1 = (struct witness *) 0xc0686b28
> td = (struct thread *) 0xc13df000
> ---Type to continue, or q to quit---
> i = -1067755093
> j = -910530880
> __func__ = "witness_checkorder"
> #4 0xc048a5fa in _mtx_lock_flags (m=0xc1580110, opts=0,
> file=0xc05f619e "/usr/src/sys/kern/kern_event.c", line=1453)
> at /usr/src/sys/kern/kern_mutex.c:271
> No locals.
> #5 0xc0476d25 in knote (list=0xc1580098, hint=0, islocked=0)
> at /usr/src/sys/kern/kern_event.c:1453
> kq = (struct kqueue *) 0xc1580038
> kn = (struct knote *) 0xc158
> #6 0xc04c934e in ttwwakeup (tp=0xc158) at /usr/src/sys/kern/tty.c:2394
> No locals.
> #7 0xc05ba441 in scstart (tp=0xc158)
> at /usr/src/sys/dev/syscons/syscons.c:1369
> rbp = (struct clist *) 0xc1580038
> len = 0
> buf =
> "\fziÃ\200\a\000\000\000p\000\000\000ziÃlgÂÃb`[Ã\fziÃ\200\a\000\000
> \000\000\000\000p\000\000BK\000
> \\gÂÃ:z[ÃÃ\235hÃ\fziÃ\000ziÃ\000\a\000\000\224gÂÃ\225a[Ã\000ziÃ\200\a\000\000
>
> \000\000\000\000\a\000\000\000\000\000\000\000ziÃ\000ziÃÃ\235hÃÅgÂÃ\016Ã[Ã\000ziÃ\200\a\000\000\000\000\000"
> scp = (scr_stat *) 0xc1697a00
> #8 0xc05bd825 in scgetc (sc=0xc0689dc0, flags=3)
> at /usr/src/sys/dev/syscons/syscons.c:3211
> ---Type to continue, or q to quit---
> scp = (scr_stat *) 0xc1697a00
> tp = (struct tty *) 0x0
> c = 6
> this_scr = -910530592
> f = 0
> i = 0
> #9 0xc05ba899 in sccngetch (flags=2)
> at /usr/src/sys/dev/syscons/syscons.c:1555
> fkey = {str = "\033[A", '\0' , len = 3 '\003'}
> fkeycp = 3
> scp = (scr_stat *) 0xc1697a00
> p = (u_char *) 0x0
> cur_mode = 1
> c = -1067204928
> #10 0xc05ba6e2 in sccncheckc (cd=0xc0634480)
> at /usr/src/sys/dev/syscons/syscons.c:1478
> No locals.
> #11 0xc04cbc98 in cncheckc () at /usr/src/sys/kern/tty_cons.c:567
> cnd = (struct cn_device *) 0xc066c480
> cn = (struct consdev *) 0x0
> c = 0
> #12 0xc04cbc45 in cngetc () at /usr/src/sys/kern/tty_cons.c:548
> c = 0
> #13 0xc042a535 in db_readline (lstart=0xc063bec0 "c\n", lsize=120)
> ---Type to continue, or q to quit---
> at /usr/src/sys/ddb/db_input.c:324
> No locals.
> #14 0xc042a67a in db_read_line () at /usr/src/sys/ddb/db_lex.c:55
> i = 0
> #15 0xc0428d91 in db_command_loop () at /usr/src/sys/ddb/db_command.c:453
> No locals.
> #16 0xc042aef5 in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_main.c:221
> jb = {{_jb = {-910530388, -910530416, -910530336, -1052905472, 0,
> -1069371754, 0, 0, 0, 0, -910530336, -1068824416}}}
> prev_jb = (void *) 0x0
> bkpt = 0
> #17 0xc04b0927 in kdb_trap (type=0, code=0, tf=0xc9ba6940)
> at /usr/src/sys/kern/subr_kdb.c:418
> handled = -910530240
> #18 0xc05d8948 in trap (frame=
> {tf_fs = -1051983848, tf_es = 16, tf_ds = -910557168, tf_edi = 9,
> tf_esi = -1051954588, tf_ebp = -910530168, tf_isp = -910530196, tf_ebx =
> -1067007556, tf_edx = 1, tf_ecx = -1056878592, tf_eax = 31, tf_trapno = 3,
> tf_err = 0, tf_eip = -1068825056, tf_cs = 8, tf_eflags = 646, tf_esp =
> -1067470996, tf_ss = -1067540423}) at /usr/src/sys/i386/i386/trap.c:576
> td = (struct thread *) 0xc13df000
> p = (struct proc *) 0xc13e61c4
> sticks = 0
> i = 0
> ---Type to continue, or q to quit---
> ucode = 0
> type = 3
> code = 0
> eva = 0
> #19 0xc05c7d2a in calltrap () at /usr/src/sys/i386/i386/exception.s:140
> No locals.
> #20 0xc14c0018 in ??
Re: problems with bge and cisco gbic-t sfp
On the Cisco interface side, try: No speed nonegotiate Mike -- Michael K. Smith[EMAIL PROTECTED] Senior Network and Systems Engineer NoaNet (206) 963-3679 http://www.noanet.net > From: Doug White <[EMAIL PROTECTED]> > Date: Fri, 8 Apr 2005 10:26:15 -0700 (PDT) > To: kama <[EMAIL PROTECTED]> > Cc: > Subject: Re: problems with bge and cisco gbic-t sfp > > On Thu, 7 Apr 2005, kama wrote: > >> I have a problem with the connection between my bge card and a cisco 7609 >> with a gbic-t sfp. >> >> uname >> 5.4-STABLE FreeBSD 5.4-STABLE #0: Tue Apr 5 11:21:17 CEST 2005. >> >> dmesg >> bge0: mem >> 0xf7df-0xf7df irq 29 at device 1.0 on pci2 >> miibus0: on bge0 >> brgphy0: on miibus0 >> brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, >> 1000baseTX-FDX, auto >> bge0: Ethernet address: 00:0d:9d:93:f1:dd >> >> ifconfig >> bge0: flags=9843 mtu 1500 >> options=1a >> inet X.X.X.X netmask 0xfffc broadcast X.X.X.X >> ether 00:0d:9d:93:f1:dd >> media: Ethernet 1000baseTX >> status: active >> >> When I run ifconfig repeatitly I get strange answers on media. >> >> media: Ethernet 1000baseTX (10GBASE-SR ) >> media: Ethernet 1000baseTX (10baseT ) >> ... >> >> Sometimes the status changes to none and back to active. >> >> On the other end I get nothing... The interface looks like its up and >> everything is OK. But it does not recognise the up and down as I see the >> status. I can reboot the system without it noticing anything. I dont think >> its a problem with the cisco hardware, but a bge driver issue or something >> related to the driver, like mii. The cables are CAT-6. The GBIC-T can only >> run at 1000base-T. >> >> I have other servers connected through an older and bigger GBIC-T and I >> cant find any problems on those. But they are running FreeBSD 4.x and not >> 5.x > > Try these, in order: > > 1. Replace the cables. > 2. Force the media types on both ends. Ciscos are famously picky about > autoneg. > > -- > Doug White| FreeBSD: The Power to Serve > [EMAIL PROTECTED] | www.FreeBSD.org > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: problems with bge and cisco gbic-t sfp
On Thu, 7 Apr 2005, kama wrote: > I have a problem with the connection between my bge card and a cisco 7609 > with a gbic-t sfp. > > uname > 5.4-STABLE FreeBSD 5.4-STABLE #0: Tue Apr 5 11:21:17 CEST 2005. > > dmesg > bge0: mem > 0xf7df-0xf7df irq 29 at device 1.0 on pci2 > miibus0: on bge0 > brgphy0: on miibus0 > brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, > 1000baseTX-FDX, auto > bge0: Ethernet address: 00:0d:9d:93:f1:dd > > ifconfig > bge0: flags=9843 mtu 1500 > options=1a > inet X.X.X.X netmask 0xfffc broadcast X.X.X.X > ether 00:0d:9d:93:f1:dd > media: Ethernet 1000baseTX > status: active > > When I run ifconfig repeatitly I get strange answers on media. > > media: Ethernet 1000baseTX (10GBASE-SR ) > media: Ethernet 1000baseTX (10baseT ) > ... > > Sometimes the status changes to none and back to active. > > On the other end I get nothing... The interface looks like its up and > everything is OK. But it does not recognise the up and down as I see the > status. I can reboot the system without it noticing anything. I dont think > its a problem with the cisco hardware, but a bge driver issue or something > related to the driver, like mii. The cables are CAT-6. The GBIC-T can only > run at 1000base-T. > > I have other servers connected through an older and bigger GBIC-T and I > cant find any problems on those. But they are running FreeBSD 4.x and not > 5.x Try these, in order: 1. Replace the cables. 2. Force the media types on both ends. Ciscos are famously picky about autoneg. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 5.4-STABLE kernel panic - usb related?
At 12:55 PM 08/04/2005, Doug White wrote: This is a known bug. ucom does some funky USB gyrations to force the port to flush and it trips over itself. I don't have the PR handy but there's one filed with a description of the underlying issue from bde. kern/79420 The patch that Ian Dowse provided fixed the panics for me. Perhaps try it in your setup. Note, this does not happen in CURRENT, only RELENG_5, but the patch does seem to work around the issue for me. ---Mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: IBM eServer 346 ServeRaid is too slow
In the future, don't cross post -questions and other lists. I'm leaving the cc: on since we may have people watching the thread, but please remove -questions for any followups. Thanks. On Thu, 7 Apr 2005, Brian Behlendorf wrote: > On Thu, 7 Apr 2005, Carl Makin wrote: > > I'd say you are seeing the same as I am with the same card in a Dell 1855. > > There is something wrong with the mpt driver and the disks when they are > > setup in a raid0 set. If you split the disks and use them as individual > > drives then you will get full performance. > > It's also a known problem, though not being tracked very well. > > http://lists.freebsd.org/pipermail/freebsd-scsi/2004-December/001577.html > http://lists.freebsd.org/pipermail/freebsd-scsi/2004-December/001578.html > > Doesn't look like (from viewcvs.cgi) there's been any recent work on > this. We're waiting on a driver update that is tied up in legalities at the moment. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Powervault 220S (cluster mode) + PERC4/DC
On Wed, 6 Apr 2005, Marcus Grando wrote: > Hi list, > > Someone use Powervault 220S (cluster mode) + PERC4/DC in FreeBSD? Any > problems? or in FreeBSD don't work in cluster mode? No, I don't believe FreeBSD supports amr cluster operation. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: pf and http (ebay)?
On Friday 08 April 2005 18:41, Dick Davies wrote:
> I have pf running on my laptop with a config including:
>
> pass out on $ext_if proto { tcp, udp } all keep state
>
> (there's a 'block in log all' and a couple of services allowed in too
> further up, but that's the gist of it.)
>
> which works well for some sites but not all. In particular,
> going to 'my ebay' hangs firefox with a
>
> 'waiting for include.ebaystatic.com'
>
> message on the status bar.
>
> pflog looks like:
>
> root$ tcpdump -r /var/log/pflog|grep ebay
> reading from file /var/log/pflog, link-type PFLOG (OpenBSD pflog file)
> 17:29:56.885697 IP my.intl.ebay.com.http > laptop.ip.60674: R
> 2025419634:2025419634(0) ack 1452466570 win 64240
> 17:30:07.917906 IP search.ebay.co.uk.http > laptop.ip.52293: R
> 1766217212:1766217212(0) ack 1086438034 win 64240
>
>
> My guess is that pf is not letting the responses back from that
> server because firefox didn't request from that server?
> But ipf on the gateway (which has a similar outbound keep state rule)
> never had this problem - any idea what's going on, or how I can debug this?
The blocked packets in your log are RSTs so it's most likely a window
violation - possibly caused by ipf on the gateway?!? Please add an "-e" to
your tcpdump to see the reason for the block. You might also want to enable
debugging (pfctl -x misc) and watch the console for "bad state" messages.
--
/"\ Best regards, | [EMAIL PROTECTED]
\ / Max Laier | ICQ #67774661
X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED]
/ \ ASCII Ribbon Campaign | Against HTML Mail and News
pgpwF6SMfaU8B.pgp
Description: PGP signature
Re: 4.11R panics
On Wed, 6 Apr 2005, Kirill Ponomarew wrote:
> Fatal trap 12: page fault while in kernel mode
> fault virtual address = 0x20202020
Hm, something ran into a bunch of ASCII spaces..
Can you jump to frame #6 and print *kbp? It appears the kernel malloc
bucket list is corrupted, so I'm curious just how badly that struct is
spammed.
> fault code= supervisor read, page not present
> instruction pointer = 0x8:0xc0193533
> stack pointer = 0x10:0xef9fbc88
> frame pointer = 0x10:0xef9fbca4
> 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 = 6866 (man)
> interrupt mask= net tty bio cam
> trap number = 12
> panic: page fault
> #0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:487
> 487 if (dumping++) {
> (kgdb) bt full
> #0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:487
> error = 0
> #1 0xc0197d4b in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:316
> howto = 256
> #2 0xc0198189 in panic (fmt=0xc02ec46c "%s") at
> /usr/src/sys/kern/kern_shutdown.c:595
> fmt = 0xc02ec46c "%s"
> bootopt = 256
> buf = "page fault", '\000'
> #3 0xc02a1203 in trap_fatal (frame=0xef9fbc48, eva=538976288) at
> /usr/src/sys/i386/i386/trap.c:974
> frame = (struct trapframe *) 0xef9fbc48
> code = 16
> type = 12
> ss = 16
> esp = 0
> softseg = {ssd_base = 0, ssd_limit = 1048575, ssd_type = 27, ssd_dpl =
> 0, ssd_p = 1, ssd_xx = 14, ssd_xx1 = 0,
> ssd_def32 = 1, ssd_gran = 1}
> #4 0xc02a0eb1 in trap_pfault (frame=0xef9fbc48, usermode=0, eva=538976288)
> at /usr/src/sys/i386/i386/trap.c:867
> va = 538976256
> vm = (struct vmspace *) 0x0
> map = 0xebdf3480
> rv = 0
> ftype = 1 '\001'
> p = (struct proc *) 0xef940f20
> #5 0xc02a0a2b in trap (frame={tf_fs = -274792432, tf_es = -947388400, tf_ds
> = -274792432, tf_edi = -1070540928,
> tf_esi = -1070485596, tf_ebp = -274744156, tf_isp = -274744204, tf_ebx
> = -1070540928, tf_edx = 9, tf_ecx = 9,
> tf_eax = 538976288, tf_trapno = 12, tf_err = 0, tf_eip = -1072089805,
> tf_cs = 8, tf_eflags = 66050, tf_esp = 0,
> tf_ss = -874502912}) at /usr/src/sys/i386/i386/trap.c:466
> p = (struct proc *) 0xef940f20
> sticks = 3553920824
> i = 0
> ucode = 0
> type = 12
> code = 0
> eva = 538976288
> #6 0xc0193533 in malloc (size=324, type=0xc030d780, flags=9) at
> /usr/src/sys/kern/kern_malloc.c:243
> type = (struct malloc_type *) 0xc030d780
> kbp = (struct kmembuckets *) 0xc031afa4
> kup = (struct kmemusage *) 0x0
> freep = (struct freelist *) 0x0
> indx = 9
> npg = 0
> allocsize = -1070540928
> s = 0
> va = 0x20202020
> cp = 0x0
> savedlist = 0x0
> ksp = (struct malloc_type *) 0x
> #7 0xc0262dee in ufsdirhash_build (ip=0xcbe02500) at
> /usr/src/sys/ufs/ufs/ufs_dirhash.c:169
> dh = (struct dirhash *) 0xcbe02500
> bp = (struct buf *) 0x0
> ep = (struct direct *) 0x700
> vp = (struct vnode *) 0xeefdd380
> bmask = 16777280
> pos = -874502912
> dirblocks = 28
> i = 0
> j = 0
> memreqd = 7562
> nblocks = 42
> narrays = 7
> nslots = 1792
> slot = 0
> #8 0xc025d9f6 in ufs_lookup (ap=0xef9fbdac) at
> /usr/src/sys/ufs/ufs/ufs_lookup.c:196
> vdp = (struct vnode *) 0xeefdd380
> dp = (struct inode *) 0xcbe02500
> bp = (struct buf *) 0x0
> ep = (struct direct *) 0x0
> entryoffsetinblock = -275509472
> slotstatus = FOUND
> slotoffset = -1
> slotsize = 0
> slotfreespace = 0
> slotneeded = 0
> numdirpasses = -274743976
> endsearch = 0
> prevoff = -1071890945
> pdp = (struct vnode *) 0x140
> tdp = (struct vnode *) 0x1ad2
> enduseful = -874473472
> bmask = 16383
> lockparent = 0
> wantparent = 0
> namlen = 0
> error = 0
> vpp = (struct vnode **) 0xef9fbe94
> cnp = (struct componentname *) 0xef9fbea8
> cred = (struct ucred *) 0xc8fc9d00
> flags = 49348
> nameiop = 0
> p = (struct proc *) 0xef940f20
> #9 0xc0262c0d in ufs_vnoperate (ap=0xef9fbdac) at
> /usr/src/sys/ufs/ufs/ufs_vnops.c:2376
> ap = (struct vop_generic_args *) 0x0
> #10 0xc01c1fda in vfs_cache_lookup (ap=0xef9fbe04) at vnode_if.h:77
> rc = 0
> a = {a_desc = 0xc02f3cc0, a_dvp = 0xeefdd380, a_vpp = 0xef9fbe94, a_cnp
> = 0xef9fbea8}
> dvp = (struct vnode *) 0xeefdd380
> vpp = (struct vnode **) 0xef9fbe94
> cnp = (struct componentname *) 0xef9fbea8
> ap = (struct vop_lookup_args *) 0x0
> dvp = (struct vnode *) 0xeefdd380
> vp = (struct vnode *) 0xef9fbdc0
> lockparen
Re: Dell PowerEdge 1855
On Wed, 6 Apr 2005, Carl Makin wrote: > I also managed to get the CD rom drive working for the install. The > sequence is this; > > . boot system with cd > . unplug usb cdrom drive when "waiting for 15 seconds" appears > . plug in the usb drive once sysinstall has started > . switch to the second virtual screen (alt-F2) and wait (approx 2 > minutes) until "cd0" appears > . switch back to sysinstall (alt-F1) and go to the "options" screen and > reprobe the hardware > . install as normal > > The boot sequence will hang if the USB drive is attached at boot. There > was something in freebsd-stable about a month ago about booting hanging > if an ipod shuffle was attached. This is showing exactly the same symptoms. > > Otherwise the machine is running well. It seems to be acting like Uthe USB controller isn't getting interrupts. Does the problem recur on the installed system? If it does, can you build a kernel with USB_DEBUG, bump up the hw.usb.debug sysctl to like 5 (I think thats what its called) then plug it in and see what you get? You should get a huge amount of spew if its working normally, or it'll slowly trickle out sets of messages if its having problems getting the controller to behave. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 5.4-STABLE kernel panic - usb related?
On Tue, 5 Apr 2005, Mars Trading wrote:
>
> Got a kernel panic starting mgetty on ucom devices from 5.4-STABLE
> as of 5-APR-0400 UTC. Wasn't able to copy the panic message though.
>
> Here's the kgdb backtrace:
>
> #0 doadump () at pcpu.h:159
> #1 0xc04bd35e in boot (howto=260)
> at /usr/src/sys/kern/kern_shutdown.c:410
> #2 0xc04bd686 in panic (fmt=0xc063db27 "%s")
> at /usr/src/sys/kern/kern_shutdown.c:566
> #3 0xc0620690 in trap_fatal (frame=0xcbee19ec, eva=0)
> at /usr/src/sys/i386/i386/trap.c:809
> #4 0xc06203a3 in trap_pfault (frame=0xcbee19ec, usermode=0, eva=76)
> at /usr/src/sys/i386/i386/trap.c:727
> #5 0xc061ff7d in trap (frame=
> {tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = 0, tf_esi =
> -1043925120, tf_ebp = -873588140, tf_isp = -873588200, tf_ebx =
> -1040863232, tf_edx = 0, tf_ecx = -1046884544, tf_eax = 0,
> tf_trapno = 12, tf_err = 0, tf_eip = -1069063351, tf_cs = 8,
> tf_eflags = 66118, tf_esp = -1046896640, tf_ss = -873588152})
> at /usr/src/sys/i386/i386/trap.c:417
> #6 0xc060e2aa in calltrap ()
> at /usr/src/sys/i386/i386/exception.s:140
> #7 0x0018 in ?? ()
> #8 0x0010 in ?? ()
> #9 0x0010 in ?? ()
> #10 0x in ?? ()
> #11 0xc1c6f780 in ?? ()
> #12 0xcbee1a54 in ?? ()
> #13 0xcbee1a18 in ?? ()
> #14 0xc1f5b000 in ?? ()
> #15 0x in ?? ()
> #16 0xc199cf40 in ?? ()
> #17 0x in ?? ()
> #18 0x000c in ?? ()
> #19 0x in ?? ()
> #20 0xc0476349 in usb_transfer_complete (xfer=0xc1f5b000)
> at /usr/src/sys/dev/usb/usbdi.c:833
> #21 0xc046e784 in uhci_abort_xfer (xfer=0xc1f5b000,
> status=USBD_NORMAL_COMPLETION)
> at /usr/src/sys/dev/usb/uhci.c:2022
> #22 0xc046e5d9 in uhci_device_bulk_abort (xfer=0x0)
> at /usr/src/sys/dev/usb/uhci.c:1921
> #23 0xc0476259 in usbd_ar_pipe (pipe=0xc1c6f780)
> at /usr/src/sys/dev/usb/usbdi.c:762
> #24 0xc0475f01 in usbd_abort_pipe (pipe=0x0)
> at /usr/src/sys/dev/usb/usbdi.c:556
> #25 0xc0c1f307 in ?? ()
> #26 0xc1c6f780 in ?? ()
> #27 0xcbee1ad8 in ?? ()
> #28 0xc0c1edc8 in ?? ()
> #29 0xc1a19400 in ?? ()
> #30 0x0001 in ?? ()
> #31 0xc1a1a400 in ?? ()
> #32 0x0003 in ?? ()
> #33 0xc18fb180 in ?? ()
> #34 0xcbee1af0 in ?? ()
> #35 0xc04f18a4 in ttyflush (tp=0xc1a19400, rw=-1046371328)
> at /usr/src/sys/kern/tty.c:1420
> Previous frame inner to this frame (corrupt stack?)
>
> Funny thing is i only got it the first time. Tried it again after a
> reboot and it worked. Hope this info will be of some use.
This is a known bug. ucom does some funky USB gyrations to force the port
to flush and it trips over itself. I don't have the PR handy but there's
one filed with a description of the underlying issue from bde.
>
> dmesg:
> Copyright (c) 1992-2005 The FreeBSD Project.
> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993,
> 1994
> The Regents of the University of California. All rights
> reserved.
> FreeBSD 5.4-STABLE #0: Tue Apr 5 14:11:56 PHT 2005
> [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GO
> Timecounter "i8254" frequency 1193182 Hz quality 0
> CPU: AMD Athlon(tm) Processor (751.33-MHz 686-class CPU)
> Origin = "AuthenticAMD" Id = 0x642 Stepping = 2
>
> Features=0x183f9ff
> AMD Features=0xc044
> real memory = 268369920 (255 MB)
> avail memory = 248782848 (237 MB)
> npx0: on motherboard
> npx0: INT 16 interface
> acpi0: on motherboard
> acpi0: Power Button (fixed)
> Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000
> acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on
> acpi0
> cpu0: on acpi0
> acpi_throttle0: on cpu0
> acpi_button0: on acpi0
> pcib0: port
> 0x6000-0x607f,0x5000-0x500f,0x4080-0x40ff,0x4000-0x407f,0xcf8-0xcff
> on acpi0
> pci0: on pcib0
> pcib1: at device 1.0 on pci0
> pci1: on pcib1
> nvidia0: mem
> 0xd800-0xd807,0xd000-0xd7ff,0xe200-0xe2ff
> irq 10 at device 0.0 on pci1
> uhci0: port 0xc000-0xc01f irq 5 at
> device 5.0 on pci0
> usb0: on uhci0
> usb0: USB revision 1.0
> uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
> uhub0: 2 ports with 2 removable, self powered
> uhci1: port 0xc400-0xc41f irq 11 at
> device 5.1 on pci0
> usb1: on uhci1
> usb1: USB revision 1.0
> uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
> uhub1: 2 ports with 2 removable, self powered
> ehci0: mem 0xe5001000-0xe50010ff irq
> 10 at device 5.2 on pci0
> usb2: EHCI version 1.0
> usb2: companion controllers, 2 ports each: usb0 usb1
> usb2: on ehci0
> usb2: USB revision 2.0
> uhub2: VIA EHCI root hub, class 9/0, rev 2.00/1.00, addr 1
> uhub2: 4 ports with 4 removable, self powered
> xl0: <3Com 3c905C-TX Fast Etherlink XL> port 0xc800-0xc87f mem
> 0xe500-0xe57f irq 11 at device 6.0 on pci0
> miibus0: on xl0
> ukphy0: on miibus0
> ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
> xl0: Ethernet address: 00:04:75:98:bb:d3
> lnc0: port 0xcc00-0xcc1f mem
> 0xe5002000-0xe500201f irq 10 at device 7.0 on pci0
> lnc0: Attachi
pf and http (ebay)?
I have pf running on my laptop with a config including:
pass out on $ext_if proto { tcp, udp } all keep state
(there's a 'block in log all' and a couple of services allowed in too
further up, but that's the gist of it.)
which works well for some sites but not all. In particular,
going to 'my ebay' hangs firefox with a
'waiting for include.ebaystatic.com'
message on the status bar.
pflog looks like:
root$ tcpdump -r /var/log/pflog|grep ebay
reading from file /var/log/pflog, link-type PFLOG (OpenBSD pflog file)
17:29:56.885697 IP my.intl.ebay.com.http > laptop.ip.60674: R
2025419634:2025419634(0) ack 1452466570 win 64240
17:30:07.917906 IP search.ebay.co.uk.http > laptop.ip.52293: R
1766217212:1766217212(0) ack 1086438034 win 64240
My guess is that pf is not letting the responses back from that
server because firefox didn't request from that server?
But ipf on the gateway (which has a similar outbound keep state rule)
never had this problem - any idea what's going on, or how I can debug this?
Thanks!
--
'And if you think you're going to bleed all over me
you're even wronger than you normally be'
-- The Specials, 'Little Bitch'
Rasputin :: Jack of All Trades - Master of Nuns
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Error reading CD on 5.4 RC1
I am not sure this is directly related to 5.4 RC1 any suggestions are appreciated. acd0: FAILURE - READ_BIG HARDWARE ERROR asc=0x08 ascq=0x03 error=0 acd0: TIMEOUT - READ_BIG retrying (2 retries left) also had this from the install: acd0: FAILURE - READ_BIG HARDWARE ERROR asc=0x08 ascq=0x03 error=0 acd0: WARNING - READ_BIG read data overrun 2048>0 acd0: TIMEOUT - READ_BIG retrying (2 retries left) acd0: unknown transfer phase acd0: WARNING - READ_BIG read data overrun 18>0 acd0: FAILURE - READ_BIG HARDWARE ERROR asc=0x08 ascq=0x03 error=0 Notes on weird stuff: 1) Does not seem to happen until I install my Adaptec SCSI RAID 2230S. Don't know why. 2) I need to use 5.4 to get support for 2230S without patching. 3) cpio hangs at this error. IE: during install I get a hang or running sysinstall to install ports etc. 4) acd0: DVDROM at ata0-master UDMA33, previous 2 systems I setup used a CD drive with no problems (May be related to Teac DVD?) %uname -a FreeBSD odo.icarz.com 5.4-RC1 FreeBSD 5.4-RC1 #0: Sun Apr 3 15:40:32 UTC 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 % %dmesg Copyright (c) 1992-2005 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.4-RC1 #0: Sun Apr 3 15:40:32 UTC 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(TM) CPU 3.00GHz (2992.71-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf41 Stepping = 1 Features=0xbfebfbff Hyperthreading: 2 logical CPUs real memory = 2952527872 (2815 MB) avail memory = 2886893568 (2753 MB) ACPI APIC Table: ioapic0: Changing APIC ID to 8 ioapic1: Changing APIC ID to 9 ioapic1: WARNING: intbase 32 != expected base 24 ioapic2: Changing APIC ID to 10 ioapic2: WARNING: intbase 64 != expected base 56 ioapic3: Changing APIC ID to 11 ioapic3: WARNING: intbase 96 != expected base 88 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 32-55 on motherboard ioapic2 irqs 64-87 on motherboard ioapic3 irqs 96-119 on motherboard npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 2.0 on pci0 pci1: on pcib1 pcib2: at device 0.0 on pci1 pci2: on pcib2 pcib3: at device 0.2 on pci1 pci3: on pcib3 pcib4: at device 4.0 on pci0 pci4: on pcib4 pcib5: at device 5.0 on pci0 pci5: on pcib5 pcib6: at device 0.0 on pci5 pci6: on pcib6 em0: port 0xdcc0-0xdcff mem 0xd86e-0xd86f irq 64 at device 7.0 on pci6 em0: Ethernet address: 00:11:43:ed:7f:52 em0: Speed:N/A Duplex:N/A pcib7: at device 0.2 on pci5 pci7: on pcib7 em1: port 0xccc0-0xccff mem 0xd84e-0xd84f irq 65 at device 8.0 on pci7 em1: Ethernet address: 00:11:43:ed:7f:53 em1: Speed:N/A Duplex:N/A pcib8: at device 6.0 on pci0 pci8: on pcib8 pcib9: at device 0.0 on pci8 pci9: on pcib9 aac0: mem 0xc800-0xcfff,0xd700-0xd77f irq 106 at device 4.0 on pci9 aac0: Unknown processor 200MHz, 112MB cache memory, optional battery not installed aac0: Kernel 4.2-0, Build 7348, S/N 264aec aac0: Supported Options=31d7c aacp0: on aac0 aacp1: on aac0 pcib10: at device 0.2 on pci8 pci10: on pcib10 uhci0: port 0x9ce0-0x9cff irq 16 at device 29.0 on pci0 usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0x9cc0-0x9cdf irq 19 at device 29.1 on pci0 usb1: on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0x9ca0-0x9cbf irq 18 at device 29.2 on pci0 usb2: on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered pci0: at device 29.7 (no driver attached) pcib11: at device 30.0 on pci0 pci11: on pcib11 pci11: at device 13.0 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0xfc00-0xfc0f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 31.1 on pci0 ata0: channel #0 on atapci0 ata1: channel #1 on atapci0 fdc0: port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on acpi0 atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 psm0: irq 12 on atkbdc0 psm0: model IntelliMouse Explorer, device ID 4 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A orm0: at iomem 0xec000-0xe,0xd0800-0xd17ff,0xcc000-0xd07ff,0xcb000-0xcbfff,0xc-0xcafff on isa0 pmtimer0 on isa0 ppc0: parallel port not found. sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may
5.4-STABLE panic
Hi,
has anyone seen this panic yet? It appears to be LOR-related :
[GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so:
Undefined symbol "ps_pglobal_lookup"]
GNU gdb 6.1.1 [FreeBSD]
#0 doadump () at pcpu.h:159
159 pcpu.h: No such file or directory.
in pcpu.h
(kgdb) bt f
#0 doadump () at pcpu.h:159
No locals.
#1 0xc04944ea in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:410
first_buf_printf = 1
#2 0xc0494858 in panic (
fmt=0xc05fc48f "blockable sleep lock (%s) %s @ %s:%d")
at /usr/src/sys/kern/kern_shutdown.c:566
td = (struct thread *) 0xc13df000
bootopt = 256
newpanic = 1
ap = 0xc9ba6670 "ÃÅ`ÃÃÃ_Ã\236a_ÃÂ\005"
buf = "blockable sleep lock (sleep mutex) tty @
/usr/src/sys/kern/kern_event.c:1453", '\0'
#3 0xc04bb0ae in witness_checkorder (lock=0xc1580110, flags=9,
file=0xc05f619e "/usr/src/sys/kern/kern_event.c", line=1453)
at /usr/src/sys/kern/subr_witness.c:709
lock_list = (struct lock_list_entry **) 0xf00
lle = (struct lock_list_entry *) 0x20
lock1 = (struct lock_instance *) 0xc13df000
lock2 = (struct lock_instance *) 0x0
class = (struct lock_class *) 0xc062045c
w = (struct witness *) 0xc0648808
w1 = (struct witness *) 0xc0686b28
td = (struct thread *) 0xc13df000
---Type to continue, or q to quit---
i = -1067755093
j = -910530880
__func__ = "witness_checkorder"
#4 0xc048a5fa in _mtx_lock_flags (m=0xc1580110, opts=0,
file=0xc05f619e "/usr/src/sys/kern/kern_event.c", line=1453)
at /usr/src/sys/kern/kern_mutex.c:271
No locals.
#5 0xc0476d25 in knote (list=0xc1580098, hint=0, islocked=0)
at /usr/src/sys/kern/kern_event.c:1453
kq = (struct kqueue *) 0xc1580038
kn = (struct knote *) 0xc158
#6 0xc04c934e in ttwwakeup (tp=0xc158) at /usr/src/sys/kern/tty.c:2394
No locals.
#7 0xc05ba441 in scstart (tp=0xc158)
at /usr/src/sys/dev/syscons/syscons.c:1369
rbp = (struct clist *) 0xc1580038
len = 0
buf =
"\fziÃ\200\a\000\000\000p\000\000\000ziÃlgÂÃb`[Ã\fziÃ\200\a\000\000
\000\000\000\000p\000\000BK\000
\\gÂÃ:z[ÃÃ\235hÃ\fziÃ\000ziÃ\000\a\000\000\224gÂÃ\225a[Ã\000ziÃ\200\a\000\000
\000\000\000\000\a\000\000\000\000\000\000\000ziÃ\000ziÃÃ\235hÃÅgÂÃ\016Ã[Ã\000ziÃ\200\a\000\000\000\000\000"
scp = (scr_stat *) 0xc1697a00
#8 0xc05bd825 in scgetc (sc=0xc0689dc0, flags=3)
at /usr/src/sys/dev/syscons/syscons.c:3211
---Type to continue, or q to quit---
scp = (scr_stat *) 0xc1697a00
tp = (struct tty *) 0x0
c = 6
this_scr = -910530592
f = 0
i = 0
#9 0xc05ba899 in sccngetch (flags=2)
at /usr/src/sys/dev/syscons/syscons.c:1555
fkey = {str = "\033[A", '\0' , len = 3 '\003'}
fkeycp = 3
scp = (scr_stat *) 0xc1697a00
p = (u_char *) 0x0
cur_mode = 1
c = -1067204928
#10 0xc05ba6e2 in sccncheckc (cd=0xc0634480)
at /usr/src/sys/dev/syscons/syscons.c:1478
No locals.
#11 0xc04cbc98 in cncheckc () at /usr/src/sys/kern/tty_cons.c:567
cnd = (struct cn_device *) 0xc066c480
cn = (struct consdev *) 0x0
c = 0
#12 0xc04cbc45 in cngetc () at /usr/src/sys/kern/tty_cons.c:548
c = 0
#13 0xc042a535 in db_readline (lstart=0xc063bec0 "c\n", lsize=120)
---Type to continue, or q to quit---
at /usr/src/sys/ddb/db_input.c:324
No locals.
#14 0xc042a67a in db_read_line () at /usr/src/sys/ddb/db_lex.c:55
i = 0
#15 0xc0428d91 in db_command_loop () at /usr/src/sys/ddb/db_command.c:453
No locals.
#16 0xc042aef5 in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_main.c:221
jb = {{_jb = {-910530388, -910530416, -910530336, -1052905472, 0,
-1069371754, 0, 0, 0, 0, -910530336, -1068824416}}}
prev_jb = (void *) 0x0
bkpt = 0
#17 0xc04b0927 in kdb_trap (type=0, code=0, tf=0xc9ba6940)
at /usr/src/sys/kern/subr_kdb.c:418
handled = -910530240
#18 0xc05d8948 in trap (frame=
{tf_fs = -1051983848, tf_es = 16, tf_ds = -910557168, tf_edi = 9, tf_esi
= -1051954588, tf_ebp = -910530168, tf_isp = -910530196, tf_ebx = -1067007556,
tf_edx = 1, tf_ecx = -1056878592, tf_eax = 31, tf_trapno = 3, tf_err = 0,
tf_eip = -1068825056, tf_cs = 8, tf_eflags = 646, tf_esp = -1067470996, tf_ss =
-1067540423}) at /usr/src/sys/i386/i386/trap.c:576
td = (struct thread *) 0xc13df000
p = (struct proc *) 0xc13e61c4
sticks = 0
i = 0
---Type to continue, or q to quit---
ucode = 0
type = 3
code = 0
eva = 0
#19 0xc05c7d2a in calltrap () at /usr/src/sys/i386/i386/exception.s:140
No locals.
#20 0xc14c0018 in ?? ()
No symbol table info available.
#21 0x0010 in ?? ()
No symbol table info available.
#22 0xc9ba0010 in ?? ()
No symbol table info available.
#23 0x0009 in ?? ()
No symbol table info available.
#24 0xc14c7264 in ?? ()
No symbol table i
[no subject]
galih_keren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 5.4-PRERELEASE pccard problem
Doug White <[EMAIL PROTECTED]> writes: > On Sun, 3 Apr 2005, Christian Laursen wrote: > > Anyway, I tried blowing away /usr/obj, cvsupping to RELENG_5_4, built world > > and kernel and installed both. > > > > And it still panics with the exact same stack trace. :( > > Old kernel module somewhere? I dont think so. The only modules I can find on the machine are located under /boot/kernel, /boot/kernel.old and /usr/obj. Besides, neither pccard nor if_wi are loaded from modules but built into the kernel. To further comlicate matters the card works some of the time but I have been unable to find a pattern suggesting what could cause the problem. -- Christian Laursen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: nfsiod tasks started in error
On Thu, Apr 07, 2005 at 02:28:21PM -0700, Kris Kennaway wrote: > On Thu, Apr 07, 2005 at 05:06:07PM -0400, [EMAIL PROTECTED] wrote: > > Plan and simple. It's a security hole. > > OK, you've changed your mind; last time you were claiming it was a > waste of resources. And, FWIW, I don't believe having nfsiod running is likely to be a security hole in the way people might think, as nfsiod doesn't open any network connections/ports/whatever unless you're actually acting as an NFS client. David. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 5.4-PRERELEASE pccard problem
Doug White <[EMAIL PROTECTED]> writes: > On Tue, 5 Apr 2005, Christian Laursen wrote: > > > Doug White <[EMAIL PROTECTED]> writes: > > > > > On Sat, 2 Apr 2005, Christian Laursen wrote: > > > > > > > After upgrading to 5.4-PRERELEASE as of yesterday, I now have a problem > > > > with my wireless card that has worked fine before. > > > > I now suspect that my wireless card might be going bad. Could a faulty card > > cause a panic like that? > > Certainly could if it is causing random memory corruption. It now seems that the card is not faulty. I tried another card and got the same panic. :( -- Christian Laursen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: FreeBSD 4.11-Release IPS device issues
David, Nice to hear it is not just me! Cheers, Anthony. -Original Message- From: David Sze [mailto:[EMAIL PROTECTED] Sent: 07 April 2005 14:31 To: Anthony Downer Cc: freebsd-stable@freebsd.org Subject: Re: FreeBSD 4.11-Release IPS device issues At 09:13 AM 06/04/2005 +0100, Anthony Downer wrote this to All: >Hello Folks, > >(I am afraid) we are using FreeBSD as the initial boot/hardware/disk >configuration tool for our Standard Windows Server builds. > >We have a bootable CD that identifies hardware, partitions disk zero, >copies the install files over and commences the Windows installation >process. > >This is working fine on a large number of machines/scsi controllers, >but the ServeRAID is causing some issues. >I am attempting to use the 4.11-Release IPS driver on an IBM xSeries >342 with a ServeRAID 4Lx RAID controller. >(Controller BIOS/Firmware 7.10.18 - Two 18GB drives in a mirrored >formation) > >Whilst we have successfully tested 5.3 with the IPS driver for this >purpose we are getting some odd errors in 4.11 (At this time it is not >possible to migrate to 5.3 for our purposes) > >When copying a large number of files (the i386 folder) using cp from a >mounted CD to a DOS formatted partition on ipsd0 we are getting the >following errors: >---cut here--- >devstat_end_transaction: HELP!! busy_count for ipsd0 is < 0 (-1)! >panic: vwakeup: neg numoutput > >syncing disks... ips0: WARNING: command timeout. Adapter is in toaster >mode, resetting to known state >devstat_end_transaction: HELP!! busy_count for ipsd0 is < 0 (-1)! >ips0: resetting adapter, this may take up to 5 minutes >ips0: syncing config >ips0: ERROR: unable to get a command! can't sync cache! >ips0: adapter clear failed >ips0: AIEE! adapter reset failed, giving up and going home! Have a nice >day. >---cut here--- I get the same panic on an IBM xSeries 346 with a ServeRAID-7k controller (Six 15K RPM 36GB drives, two as RAID1, four as RAID0). The panic occurs at random points while sysinstall is copying distributions. If I do a minimal install, that completes successfully, but then the same panic occurs while building a new kernel. 5.4-RC1 seems to work fine, but I'm in the same boat as you; my customer doesn't want to upgrade to RELENG_5 yet. I'm going to look at backporting the -CURRENT ips driver to RELENG_4, I'll post patches (and a PR) if I'm successful. - Visit our Internet site at http://www.reuters.com To find out more about Reuters Products and Services visit http://www.reuters.com/productinfo Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Sound problem
> You don't have to put "device sound" in your kernel config. I use the > following in /boot/loader.conf: > sound_load="YES" > snd_es137x_load="YES" > > I wonder if you are experiencing some weird interaction between using > snd_via8233 as a module and compiling device sound into the kernel. Try > either compiling everything into the kernel or only using modules for > sound. > > Jon Well im not sure if what you suggested was the reasoning behind it fixing itself and allowing me ot laod the sound module .. but after taking your advice and removing sound from the kernel cvsupin everything and rechecking all cables .. it miraculously allowed me to load the drivers, so thanks. -- Yours Sincerely Shinjii http://www.shinji.nq.nu ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
