INCREDIBLE .. WORLDS NO.1 !!
Ladies & Gentlemen, Are you ready to the experience of a lifetime ? As affiliates of the CIL group, we offer you to PLUGIN to the largest SEX-SERVER on the WEB, in order to get more than 3000 MegaBytes of the best and most sensational SEX on the entire Web! Why on earth do you think that thousands of people from 13 countries daily choose to visit 2 particular WebSites ? Very EASY answer! - The largest and most incredible content of LIVE SEX is offered! - State-of-the-art LIVE SHOWS with the wildest and most horny amateurs and pornstars in the world! - Hardcore LIVE SEX that hasn´t crossed your imagination! - Incredible & amazing themes from soft sex to the most bizarre sex! - Beautiful Girls & wild studs from almost every country, allowing you to watch, see & chat with awsome amateurs & pornstars who are blond, who are black, who are Scandinavian, who are Asian, who have BIG tits, who are shaved, who are pregnant who are you just name it ! - The best ever made SPY-CAMS, WATCH-CAMS, POOL-CAMS, SHOWER-CAMS, AMATEUR-CAMS ... etc! - Several high quality Interactive Cams & LIVE SEX Chat, where you are in controle ! - Much much more ... too much to mention ! EVERYTHING is offered 100% ANONOMOUSLY & you don´t need to sign-up or have a creditcard ... How simple is that ? PLUGIN now to our MEGA SEX-SERVER through any of the 2 AwardWinning Sites listed below, and get instantly access to more than 3000 MegaBytes of State-of-the-art WebSex! RIGHT HERE AT: http://siam.to/sexywebtv (This Site just has EVERYTHING you can imagine) ... If this Site does not open properly ... please try http://cyberu.to/hotweb Or this one, if you just love true LESBIAN SEX, CHAT and MORE from Sunny Ibiza in Spain: http://siam.to/sexybabestv ... If this Site does not open properly ... please try http://cyberu.to/hotbabes Enjoy your trip to paradise! VERY IMPORTANT HINT: To get DIRECT ACCESS to the webpages in the future, ALLWAYS keep the DIALER on your desktop or elsewhere on your PC ... Its easy, small and 100% harmless. Yours sincerely, WORLD1-WEB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: filesystem errors
To: Michael Harnois <[EMAIL PROTECTED]>
cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: filesystem errors
In-Reply-To: Your message of "Wed, 25 Jul 2001 23:14:16 CDT."
<[EMAIL PROTECTED]>
Date: Thu, 26 Jul 2001 15:14:09 +0100
From: Ian Dowse <[EMAIL PROTECTED]>
In message <[EMAIL PROTECTED]>,
Michael Harnois writes:
>I'm tearing my hair out trying to find a filesystem error that's
>causing me a panic: ufsdirhash_checkblock: bad dir inode.
>
>When I run fsck from a single user boot, it finds no errors.
>
>When I run it on the same filesystem mounted, it finds errors: but, of
>course, it then can't correct them
[Kirk, I'm cc'ing you because here the dirhash code sanity checks
found a directory entry with d_ino == 0 that was not at the start
of a DIRBLKSIZ block. This doesn't happen normally, but it seems
from this report that fsck does not correct this. Is it a basic
filesystem assumption that d_ino == 0 can only happen at the start
of a directory block, or is it something the code should tolerate?]
FFS will never set a directory ino == 0 at a location other
than the first entry in a directory, but fsck will do so to
get rid of an unwanted entry. The readdir routines know to
skip over an ino == 0 entry no matter where in the directory
it is found, so applications will never see such entries.
It would be a fair amount of work to change fsck to `do the
right thing', as the checking code is given only the current
entry with which to work. I am of the opinion that you
should simply accept that mid-directory block ino == 0 is
acceptable rather than trying to `fix' the problem.
Interesting - this is an error reported by the UFS_DIRHASH code
that you enabled in your kernel config. A sanity check that the
dirhash code is performing is failing. These checks are designed
to catch bugs in the dirhash code, but in this case I think it may
be a bug that fsck is not finding this problem, or else my sanity
tests are too strict.
A workaround is to turn off the sanity checks with:
sysctl vfs.ufs.dirhash_docheck=0
or to remove UFS_DIRHASH from your kernel config. You could also
try to find the directory that is causing the problems. Copy the
following script to a file called dircheck.pl, and try running:
chmod 755 dircheck.pl
find / -fstype ufs -type d -print0 | xargs ./dircheck.pl
That should show up any directories that would fail that dirhash
sanity check - there will probably just be one or two that resulted
from some old filesystem corruption.
Ian
#!/usr/local/bin/perl
while (defined($dir = shift)) {
unless (open(DIR, "$dir")) {
print STDERR "$dir: $!\n";
next;
}
$b = 0;
my(%dir) = ();
while (sysread(DIR, $dat, 512) == 512) {
$off = 0;
while (length($dat) > 0) {
($dir{'d_ino'}, $dir{'d_reclen'}, $dir{'d_type'},
$dir{'d_namlen'}) = unpack("LSCC", $dat);
$dir{'d_name'} = substr($dat, 8, $dir{'d_namlen'});
$minreclen = (8 + $dir{'d_namlen'} + 1 + 3) & (~3);
$gapinfo = ($dir{'d_reclen'} == $minreclen) ? "" :
sprintf("[%d]", $dir{'d_reclen'} - $minreclen);
if ($dir{'d_ino'} == 0 && $off != 0) {
printf("%s off %d ino %d reclen 0x%x type 0%o"
. " namelen %d name '%s' %s\n",
$dir, $off, $dir{'d_ino'},
$dir{'d_reclen'}, $dir{'d_type'},
$dir{'d_namlen'}, $dir{'d_name'},
$gapinfo);
}
if ($dir{'d_reclen'} > length($dat)) {
die "reclen too long!\n";
}
$dat = substr($dat, $dir{'d_reclen'});
$off += $dir{'d_reclen'};
}
$b++;
}
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: filesystem errors
On Sat, 28 Jul 2001 12:48:54 -0700, Kirk McKusick <[EMAIL PROTECTED]> said: > FFS will never set a directory ino == 0 at a location other than > the first entry in a directory, but fsck will do so to get rid > of an unwanted entry. The readdir routines know to skip over an > ino == 0 entry no matter where in the directory it is found, so > applications will never see such entries. It would be a fair > amount of work to change fsck to `do the right thing', as the > checking code is given only the current entry with which to > work. I am of the opinion that you should simply accept that > mid-directory block ino == 0 is acceptable rather than trying to > `fix' the problem. I don't have sufficient technical knowledge to know which of you is right; I would just ask that filesystem corruption caused by restarting from a hung system not cause a panic . -- Michael D. Harnois bilocational bivocational Washburn, Iowa Minneapolis, Minnesota Hanlon's Razor: Never attribute to malice that which is adequately explained by stupidity. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: filesystem errors
In message <[EMAIL PROTECTED]>, Michael Harnois writes: > >I don't have sufficient technical knowledge to know which of you is >right; I would just ask that filesystem corruption caused by >restarting from a hung system not cause a panic . I removed the extra sanity check yesterday, so if you have revision 1.3 of ufs_dirhash.c you won't see that panic again. I didn't realise that fsck actually causes these directory entries, but just the fact that it leaves them intact meant that the sanity check was bad. Ian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI: Clock problems in -current
On Sat, 28 Jul 2001, Mike Smith wrote: > You could also try building a kernel with CLK_CALIBRATION_LOOP defined > and then booting with -v (without the timer disabled). This might be > instructive (I don't know for certain that it'll calibrate the ACPI > timer, since it may not have been probed yet). It won't. CLK_CALIBRATION_LOOP only iterates calibration of the i8254 and TSC timers relative to the RTC. None of the clock calibration stuff is very useful. All the clock frequencies depend on the temperature, so their values at boot time are only slightly more related to their values at run time than their values at a random time. Average values are probably better than boot time values. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
-current kernel panicing
I'm getting a panic in the -current kernel with using kernels built with src/sys/kern/kern_exit.c 1.130 and src/sys/kern/kern_sig.c 1.124 as well as with src/sys/kern/kern_exit.c 1.131 and src/sys/kern/kern_sig.c 1.125. This seems to be a problem that only passwd(1) and chpass(1) seems to cause. vipw appears to work fine as well as everything else. This is what happens: root@pele [10:55pm][~] >> passwd toor Changing local password for toor. New password: Retype new password: passwd: updating the database... passwd: done root@pele [10:55pm][~] >> root@pele [10:55pm][~] >> root@pele [10:55pm][~] >> root@pele [10:55pm][~] >> root@pele [10:55pm][~] >> root@pele [10:55pm][~] >> root@pele [10:55pm][~] >> root@pele [10:55pm][~] >> After here, it just freezes solid for 1 minute then displays on the console... Jul 27 22:57:24 pele /boot/kernel/kernel: lock order reversal Jul 27 22:57:24 pele /boot/kernel/kernel: lock order reversal Jul 27 22:57:24 pele /boot/kernel/kernel: 1st 0xda041d9c process lock @ /usr/src/sys/vm/vm_glue.c:469 Jul 27 22:57:24 pele /boot/kernel/kernel: 1st 0xda041d9c process lock @ /usr/src/sys/vm/vm_glue.c:469 Jul 27 22:57:24 pele /boot/kernel/kernel: 2nd 0xc118de00 lockmgr interlock @ /usr/src/sys/kern/kern_lock.c:239 Jul 27 22:57:24 pele /boot/kernel/kernel: 2nd 0xc118de00 lockmgr interlock @ /usr/src/sys/kern/kern_lock.c:239 Then it just hangs completely, not even a db> prompt so had to hard reboot and it goes into single user mode where one would need to fsck all the slices and then I have to: cp -p /var/backups/master.passwd.bak /etc/master.passwd since the password database somehow got corrupted and then ran vipw and :wq! and then shutdown the machine where it would boot normally. Anyone have any ideas how to solve this one or what is causing it since the previous GENERIC kernel from the 6/16/2001 build of -current seemed fine. Cheers, Vince - [EMAIL PROTECTED] - Vice President __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] WurldLink Corporation / / / / | / | __] ] San Francisco - Honolulu - Hong Kong / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] Almighty1@IRC - oahu.DAL.NET Hawaii's DALnet IRC Network Server Admin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current kernel panicing
Something wrong in the fs lock code. == WWW.XGFORCE.COM The Next Generation Load Balance and Fail Safe Server Clustering Software for the Internet. == - Original Message - From: "Vincent Poy" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, July 28, 2001 2:49 AM Subject: -current kernel panicing > I'm getting a panic in the -current kernel with using kernels > built with src/sys/kern/kern_exit.c 1.130 and src/sys/kern/kern_sig.c > 1.124 as well as with src/sys/kern/kern_exit.c 1.131 and > src/sys/kern/kern_sig.c 1.125. This seems to be a problem that only > passwd(1) and chpass(1) seems to cause. vipw appears to work fine as well > as everything else. This is what happens: > > root@pele [10:55pm][~] >> passwd toor > Changing local password for toor. > New password: > Retype new password: > passwd: updating the database... > passwd: done > root@pele [10:55pm][~] >> > root@pele [10:55pm][~] >> > root@pele [10:55pm][~] >> > root@pele [10:55pm][~] >> > root@pele [10:55pm][~] >> > root@pele [10:55pm][~] >> > root@pele [10:55pm][~] >> > root@pele [10:55pm][~] >> > After here, it just freezes solid for 1 minute then displays on > the console... > > Jul 27 22:57:24 pele /boot/kernel/kernel: lock order reversal > Jul 27 22:57:24 pele /boot/kernel/kernel: lock order reversal > Jul 27 22:57:24 pele /boot/kernel/kernel: 1st 0xda041d9c process lock @ > /usr/src/sys/vm/vm_glue.c:469 > Jul 27 22:57:24 pele /boot/kernel/kernel: 1st 0xda041d9c process lock @ > /usr/src/sys/vm/vm_glue.c:469 > Jul 27 22:57:24 pele /boot/kernel/kernel: 2nd 0xc118de00 lockmgr interlock > @ /usr/src/sys/kern/kern_lock.c:239 > Jul 27 22:57:24 pele /boot/kernel/kernel: 2nd 0xc118de00 lockmgr interlock > @ /usr/src/sys/kern/kern_lock.c:239 > > Then it just hangs completely, not even a db> prompt so had to hard reboot > and it goes into single user mode where one would need to fsck all the > slices and then I have to: > cp -p /var/backups/master.passwd.bak /etc/master.passwd > since the password database somehow got corrupted and then ran vipw and > :wq! and then shutdown the machine where it would boot normally. Anyone > have any ideas how to solve this one or what is causing it since the > previous GENERIC kernel from the 6/16/2001 build of -current seemed fine. > > Cheers, > Vince - [EMAIL PROTECTED] - Vice President __ > Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] > WurldLink Corporation / / / / | / | __] ] > San Francisco - Honolulu - Hong Kong / / / / / |/ / | __] ] > HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] > Almighty1@IRC - oahu.DAL.NET Hawaii's DALnet IRC Network Server Admin > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI: Clock problems in -current
Say set debug.acpi.disable="timer" in the bootloader and see if you still get this. I've already got one report of system time going twice as fast as it should; I'm unsure what's going on here (I don't grok the timecounter code as well as I should, I think)... You could also try building a kernel with CLK_CALIBRATION_LOOP defined and then booting with -v (without the timer disabled). This might be instructive (I don't know for certain that it'll calibrate the ACPI timer, since it may not have been probed yet). Thanks! > Hi, > > just noticed with a -current from yesterday (today's -current has the > same problem). > > After bootup I will see tons of > calcru: negative time of -953757 usec for pid 636 (make) > calcru: negative time of -820616 usec for pid 636 (make) > microuptime() went backwards (1969.4485199 -> 1969.552693) > microuptime() went backwards (1969.4485199 -> 1969.690311) > messages, together with processes with a negative CPU usage time. > > Something is going wrong during setting clock interrupts. > A "vmstat -i" shows (among other interrupts): > clk irq079496 49 > rtc irq8 101753 63 > which is about half the rate it should be. > > The latest working kernel I was booting before was from Jul, 13th > > If I disable ACPI in the kernel the interrupt rate is back to normal. > > ACPI related boot messages: > acpi0: on motherboard > acpi0: power button is handled as a fixed feature programming model. > acpi_timer0: <32-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 > acpi_cpu0: on acpi0 > acpi_button0: on acpi0 > acpi_pcib0: on acpi0 > pci0: on acpi_pcib0 > acpi_cpu0: set speed to 100.0% > acpi_cpu: CPU throttling enabled, 2 steps from 100% to 50.0% > > Mainboard is a GigaByte GA-5AX with F3 BIOS. > > > I will provide further configuration information if needed. > > > -- > Daniel > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI: Clock problems in -current
Mike Smith schrieb: > > Say > > set debug.acpi.disable="timer" > > in the bootloader and see if you still get this. I've already got one > report of system time going twice as fast as it should; I'm unsure what's > going on here (I don't grok the timecounter code as well as I should, I > think)... This helps. > > You could also try building a kernel with CLK_CALIBRATION_LOOP defined > and then booting with -v (without the timer disabled). This might be > instructive (I don't know for certain that it'll calibrate the ACPI > timer, since it may not have been probed yet). Calibrating clock(s) ... TSC clock: 300684467 Hz, i8254 clock: 1193192 Hz Calibrating clock(s) ... TSC clock: 300685043 Hz, i8254 clock: 1193195 Hz Calibrating clock(s) ... TSC clock: 300684395 Hz, i8254 clock: 1193192 Hz Calibrating clock(s) ... TSC clock: 300684395 Hz, i8254 clock: 1193192 Hz Timecounter "i8254" frequency 1193190 Hz CPU: AMD-K6(tm) 3D processor (300.68-MHz 586-class CPU) Origin = "AuthenticAMD" Id = 0x580 Stepping = 0 -- Daniel To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
NFS file locking fails from Solaris
I'm getting a strange problem in the NFS file locking code in -current. (We won't talk about -stable. It has fundamental brokenness.) FreeBSD -current Server -> Solaris 8 Rel 4/01 Client The Solaris client mounts the FreeBSD exported filesystem fine. I can create, delete, and manipulate files fine. However, when I try to use fcntl to lock a file, the Solaris client hangs. Normally, I would just let this go; however, Cadence (the VLSI CAD tool company) requires locks to work in order to use its tools. Therefore, I can't use FreeBSD as a fileserver in my environment. If I monitor the traffic on the line with ethereal, I see the request for the version 4 nlockmgr from the Solaris client to the FreeBSD server. I see the FreeBSD server respond with the correct version and port. However, after this, I start seeing a bunch of SYN/RST packets being thrown around, and I never see a lock request initiated from the Solaris client. It is certainly conceivable that there is something fundamentally broken in the Solaris code even though it works with other Solaris machines. However, I'm a bit out of my depth on this and was hoping to be able to talk to somebody and either get a confirmation that this is a known problem or that it is something that I'm doing wrong in my configuration. Who do I talk to about this? Thanks, Andy L. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI: Clock problems in -current
> Mike Smith schrieb: > > > > Say > > > > set debug.acpi.disable="timer" > > > > in the bootloader and see if you still get this. I've already got one > > report of system time going twice as fast as it should; I'm unsure what's > > going on here (I don't grok the timecounter code as well as I should, I > > think)... > > This helps. Ok. I'll go look at it again. > Calibrating clock(s) ... TSC clock: 300684467 Hz, i8254 clock: 1193192 Hz Hrm. Drat. You're running on an K6, and ACPI is working for you? I'm impressed; I guess this is a fairly new motherboard? -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
floppy driver broken?
Yesterday's current, w/NODEVFS kernel. # fdformat /dev/fd0.1440 Format 1440K floppy `/dev/fd0.1440'? (y/n): y Processing done. # mount_msdosfs /dev/fd0.1440 /floppy mount_msdosfs: /dev/fd0.1440: Invalid argument # ls -l /dev/fd0.1440 crw-r- 2 root operator9, 3 Jul 28 16:29 /dev/fd0.1440 # pkg_add -r mtools Fetching ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-current/Latest/mtools.tgz... Done. # mcopy /tmp/foo a: init A: sector size too big Cannot initialize 'A:' Bad target a: To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI: Clock problems in -current
Mike Smith schrieb: > > > Calibrating clock(s) ... TSC clock: 300684467 Hz, i8254 clock: 1193192 Hz > > Hrm. Drat. > > You're running on an K6, and ACPI is working for you? I'm impressed; I > guess this is a fairly new motherboard? No, it is an at least 3 years old GigaByte GA-5AX (Ali Aladdin V). Even the BIOS is from December 1999. -- Daniel To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: floppy driver broken?
On Sat, Jul 28, 2001 at 04:36:40PM -0700, David O'Brien wrote: > Yesterday's current, w/NODEVFS kernel. Never mind. I forgot the newfs_msdos step. :-( To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: acpica malfunctions
Thank you for your patch. Now I can boot my SONY PCG-Z505V/BP with acpi_pcib.c rev1.11 + your patch. Here's ACPI related dmesg: acpi0: on motherboard Timecounter "ACPI" frequency 3579545 Hz acpi_cpu0: on acpi0 acpi_tz0: on acpi0 acpi_button0: on acpi0 acpi_pcib0: on acpi0 pci0: on acpi_pcib0 acpi_pcib0: matched entry for 0.7.INTD (source \\_SB_.LNKD) acpi_pcib0: possible interrupts: 9 acpi_pcib0: routed interrupt 9 via \\_SB_.LNKD acpi_pcib0: matched entry for 0.12.INTA (source \\_SB_.LNKB) acpi_pcib0: possible interrupts: 9 acpi_pcib0: routed interrupt 9 via \\_SB_.LNKB Thank you, Haro From: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> Date: Fri, 27 Jul 2001 05:25:53 -0700 ::In-Reply-To: <[EMAIL PROTECTED]>; from [EMAIL PROTECTED] on :Mon, Jul 23, 2001 at 01:37:59PM -0700 :: ::On Mon, Jul 23, 2001 at 01:37:59PM -0700, Mike Smith wrote: ::> > > > 1. Acpica modules hangs in ::> > > > AcpiRsCalculateByteStreamLength() called from ::> > > > AcpiRsCreateByteStream() called from ::> > > > AcpiRsSetSrsMethodData() called from ::> > > > AcpiSetCurrentResources() from somewhere in acpi_pcib.c . ::> > > > ::> > > > The hang itself occurs at LinkedList->Id == 9 and LinkedList->Length ::> > == 0 ::> > > > . ::> > > ::> > > Can you replace &crsbuf with crsbuf in acpi_pcib.c at line 484? ::> > > I think I should be passing a pointer to the buffer, not a pointer to a ::> > > pointer. ::> > ::> > There's no &crsbuf in line 484 (not in rev 1.10, nor 1.11). ::> > ::> > Assuming you're talking about the one in line 478, it doesn't compile if you ::> > change it to crsbuf from &crsbuf, since crsbuf is an ACPI_BUFFER, not ::> > an (ACPI_BUFFER *). ::> ::> Um. Sorry about the line numbers, and yes, sorry about the confusion ::> there; I just looked at it and it seemed wrong. ::> ::> I'd still like to know the allocation length for that buffer though; my ::> last suspicion is that it doesn't contain any resources at all, and so ::> we're overrunning it when we go to try to stuff an interrupt resource ::> into it. If that's the case, it's easy to fix. If not, then we will ::> have to go hunting snarks. :: ::Mike, ::Seems like I managed to solve my problem. Attached is to be applied against ::sys/dev/acpica/acpi_pcib.c, rev 1.10 . :: ::First of all, the list returned in crsbuf was terminated with an element ::with its Length field equal to zero (and Id field was ACPI_RSTYPE_IRQ). ::Since AcpiRsCalculateByteStreamLength() expects ACPI_RSTYPE_END_TAG as ::terminator and doesn't check the validity of Length field (or, in other words, ::this function doesn't treat it as terminator), the function never returned. :: ::And as you suggested, AcpiGetCurrentResources() returned an IRQ resource ::with no interrupts(NumberOfInterrupts = 0, and no room for ::Data.Irq.Interrupts[0]). Thus the line 476 in acpi_pcib.c was overwriting ::the Id field in the next element. :: ::The patch tries to allocate another buffer to resize the list, and to modify the ::last element's Id to ACPI_RSTYPE_END_TAG. ::I think AcpiRsCalculateByteStreamLength() should just exit the while loop ::when it found an element with Length = 0, rather than wait for the end tag ::forever. :: ::Thanks. :: :: :: ::Shop Smart Compare Prices on Name-Brand Products from Name-Brand Stores!! ::http://www.smartshop.com/cgi-bin/main.cgi?ssa=4099 =-- _ _Munehiro (haro) Matsuda -|- /_\ |_|_| Business Incubation Dept., Kubota Corp. /|\ |_| |_|_| 1-3 Nihonbashi-Muromachi 3-Chome Chuo-ku Tokyo 103-8310, Japan Tel: +81-3-3245-3318 Fax: +81-3-3245-3315 Email: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current kernel panicing
Interesting... I'm running on a cvsup of July 25, 2001 17:00GMT except because of Ian Dowse mentioning in the message thread: SIGCHLD changes causing fault on nofault entry panics, I reverted back to src/sys/kern/kern_exit.c 1.130 and src/sys/kern/kern_sig.c 1.124 to test. Sometimes it will just hang. I noticed that sometimes it will say when it hangs solid: swap_pager: out of swap space swap_pager_getswapspace:failed And this machine does have 512Megs of ram and only 64 is used most of the time. Even swapinfo indicates that it's not using the swap yet. root@pele [4:23pm][/usr/home/vince] >> swapinfo Device 1K-blocks UsedAvail Capacity Type /dev/da0s1b2620160 262016 0%Interleaved >From the following output, it seems like nfs code is at fault but we're not even using nfs at all root@pele [4:24pm][/usr/home/vince] >> nm -n /boot/kernel/kernel | grep da041d9c root@pele [4:25pm][/usr/home/vince] >> nm -n /boot/kernel/kernel | grep da041d9 root@pele [4:25pm][/usr/home/vince] >> nm -n /boot/kernel/kernel | grep da041d root@pele [4:25pm][/usr/home/vince] >> nm -n /boot/kernel/kernel | grep da041 root@pele [4:25pm][/usr/home/vince] >> nm -n /boot/kernel/kernel | grep da04 c02bda04 T nfs_curusec root@pele [4:25pm][/usr/home/vince] >> nm -n /boot/kernel/kernel | grep c118de00 root@pele [4:27pm][/usr/home/vince] >> nm -n /boot/kernel/kernel | grep c118de0 root@pele [4:27pm][/usr/home/vince] >> nm -n /boot/kernel/kernel | grep c118de root@pele [4:27pm][/usr/home/vince] >> nm -n /boot/kernel/kernel | grep c118d root@pele [4:27pm][/usr/home/vince] >> nm -n /boot/kernel/kernel | grep c118 c03dc118 ? __set_sysuninit_set_sym_M_IFADDR_uninit_sys_uninit c03ec118 d twed_twe_driver_list Cheers, Vince - [EMAIL PROTECTED] - Vice President __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] WurldLink Corporation / / / / | / | __] ] San Francisco - Honolulu - Hong Kong / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] Almighty1@IRC - oahu.DAL.NET Hawaii's DALnet IRC Network Server Admin On Sat, 28 Jul 2001, matt wrote: > Something wrong in the fs lock code. > > == > WWW.XGFORCE.COM > The Next Generation Load Balance and > Fail Safe Server Clustering Software > for the Internet. > == > - Original Message - > From: "Vincent Poy" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Saturday, July 28, 2001 2:49 AM > Subject: -current kernel panicing > > > > I'm getting a panic in the -current kernel with using > kernels > > built with src/sys/kern/kern_exit.c 1.130 and > src/sys/kern/kern_sig.c > > 1.124 as well as with src/sys/kern/kern_exit.c 1.131 > and > > src/sys/kern/kern_sig.c 1.125. This seems to be a > problem that only > > passwd(1) and chpass(1) seems to cause. vipw appears > to work fine as well > > as everything else. This is what happens: > > > > root@pele [10:55pm][~] >> passwd toor > > Changing local password for toor. > > New password: > > Retype new password: > > passwd: updating the database... > > passwd: done > > root@pele [10:55pm][~] >> > > root@pele [10:55pm][~] >> > > root@pele [10:55pm][~] >> > > root@pele [10:55pm][~] >> > > root@pele [10:55pm][~] >> > > root@pele [10:55pm][~] >> > > root@pele [10:55pm][~] >> > > root@pele [10:55pm][~] >> > > After here, it just freezes solid for 1 minute then > displays on > > the console... > > > > Jul 27 22:57:24 pele /boot/kernel/kernel: lock order > reversal > > Jul 27 22:57:24 pele /boot/kernel/kernel: lock order > reversal > > Jul 27 22:57:24 pele /boot/kernel/kernel: 1st > 0xda041d9c process lock @ > > /usr/src/sys/vm/vm_glue.c:469 > > Jul 27 22:57:24 pele /boot/kernel/kernel: 1st > 0xda041d9c process lock @ > > /usr/src/sys/vm/vm_glue.c:469 > > Jul 27 22:57:24 pele /boot/kernel/kernel: 2nd > 0xc118de00 lockmgr interlock > > @ /usr/src/sys/kern/kern_lock.c:239 > > Jul 27 22:57:24 pele /boot/kernel/kernel: 2nd > 0xc118de00 lockmgr interlock > > @ /usr/src/sys/kern/kern_lock.c:239 > > > > Then it just hangs completely, not even a db> prompt > so had to hard reboot > > and it goes into single user mode where one would need > to fsck all the > > slices and then I have to: > > cp -p /var/backups/master.passwd.bak > /etc/master.passwd > > since the password database somehow got corrupted and > then ran vipw and > > :wq! and then shutdown the machine where it would boot > normally. Anyone > > have any ideas how to solve this one or what is > causing it since the > > previous GENERIC kernel from the 6/16/2001 build > of -current seemed fine. > > > > Cheers, > > Vince - [EMAIL PROTECTED] - Vice President > __ > > Unix Networking Operations - FreeBSD-Real Unix for > Free / / / / | / |[__ ] > > WurldLink Corporation > / / / / | / | __] ] > > San
