Re: Lock enabling onboard lan (Attansic L1 GbE) on 7.1-PRERELEASE
On Sat, Jan 10, 2009 at 04:07:24AM +0100, Barbara wrote: [...] Would try the following WIP version? http://people. freebsd.org/~yongari/age/if_age.c http://people.freebsd. org/~yongari/age/if_agereg.h I have no longer access to L1 hardware so I don't know whether it helps or not. -- Regards, Pyun YongHyeon Well, it works! As I've said, it's not a real problem for me, but I'm so sorry about not having tested before so it could be merged before 7.1-RELEASE, but I had it disabled and nearly forgot about that. Please, feel free to ask whenever you want if you want me doing tests on that NIC. I'm confused, the WIP version works whereas age(4) in 7.1-RELEASE didn't work right? If the WIP version works, would you show me the output of verbose boot message? -- Regards, Pyun YongHyeon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: more marvell marvels
On Fri, Jan 09, 2009 at 01:48:24PM +0200, Danny Braniss wrote: hi, the mb is asus P5K-VM, the onboard nic is, acccording to pciconf: ms...@pci0:1:0:0: class=0x02 card=0x81f81043 chip=0x436411ab rev=0x12 hdr=0x00 vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' device = '88E8056 Yukon PCI-E Gigabit Ethernet Controller' class = network subclass = ethernet cap 01[48] = powerspec 3 supports D0 D1 D2 D3 current D0 cap 03[50] = VPD cap 05[5c] = MSI supports 1 message, 64 bit cap 10[e0] = PCI-Express 1 legacy endpoint nothing new here, problems have been reported before, but: my very first attempt - after a very long time - of booting 7.1-stable, produced a panic because msk could not find its physio, by the time i had the serial console attached and working, that problem disappeared :-( now, after reboot, it sometimes hangs - because the net is not working, and only if I unplug the ethernet, (no signs of the driver seeing this), and replug things begin to work. btw, i had to set hw.msk.legacy_intr=1 to get things working. any patches for 7.1-stable to test? If memory serve me right you have Yukon EC Ultra with 88E1149 PHY, right? CURRENT has some stability fixes but the source wouldn't be compiled on stable/7 yet due to KPI differences. I have plan to add some features in next week which make it possible to use HEAD version on stable/7. I'm not sure the patch for 88E8040 could be applied to stable/7 but the patch has some fixes for link state handling. Would you give it try? http://people.freebsd.org/~yongari/msk/msk.88E8040.patch14 Note, the 88E8040 patch is not complete yet and may cause other problems too. tried to apply patches, but if_mskreg.h patches failed, and hand stitching didn't help (I have 7.1-Stable) danny -- Regards, Pyun YongHyeon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 2 (very old) bugs?
Hi, On 2009-01-09, Doug Barton wrote: Yannick Cadin wrote: - first in the stat command. Only with the -x option. If you execute stat -x on /tmp or /usr/bin/passwd parameters for example, the numeric representation of mode is wrong. The special bits are always 0. No suid-bit, no sticky bit! Our version of stat(1) is essentially an exact duplicate of the code from NetBSD. I imported this originally, but I have not not had time to merge changes for a while now. If anyone is interested in taking this on have a look at: http://cvsweb.netbsd.org/bsdweb.cgi/src/usr.bin/stat/ The reported bug still exists in the NetBSD version too. I believe that the following patch fixes the bug: %%% Index: usr.bin/stat/stat.c === --- usr.bin/stat/stat.c (revision 186786) +++ usr.bin/stat/stat.c (working copy) @@ -108,7 +108,8 @@ __FBSDID($FreeBSD$); #define LINUX_FORMAT \ File: \%N\%n \ Size: %-11z FileType: %HT%n \ - Mode: (%04OLp/%.10Sp) Uid: (%5u/%8Su) Gid: (%5g/%8Sg)%n \ + Mode: (%OMp%03OLp/%.10Sp) \ + Uid: (%5u/%8Su) Gid: (%5g/%8Sg)%n \ Device: %Hd,%Ld Inode: %iLinks: %l%n \ Access: %Sa%n \ Modify: %Sm%n \ %%% -- Jaakko ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: pciconf: incorrect description for Marvell 88SX6101 chip
on 21/11/2008 15:14 Andriy Gapon said the following: I wasn't sure where this belongs, so writing here. This is stable/7 on Intel DG33TL: $ pciconf -lv ... atap...@pci0:3:0:0: class=0x01018f card=0x610111ab chip=0x610111ab rev=0xb2 hdr=0x00 vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' device = '6101 SATA2 Controller' class = mass storage subclass = ATA ... This is actually a PATA controller (SATA is provided by ICH9). lspci is more correct: $ lspci -v ... 03:00.0 IDE interface: Marvell Technology Group Ltd. 88SE6101 single-port PATA133 interface (rev b2) (prog-if 8f [Master SecP SecO PriP PriO]) Subsystem: Marvell Technology Group Ltd. 88SE6101 single-port PATA133 interface ... ATA driver is also cool: atapci0: Marvell 88SX6101 UDMA133 controller This is very minor but still... Here's a tiny patch. diff --git a/share/misc/pci_vendors b/share/misc/pci_vendors index 8286310..c92d12e 100644 --- a/share/misc/pci_vendors +++ b/share/misc/pci_vendors @@ -4606,7 +4606,7 @@ 6041MV88SX6041 Marvell Technology Group Ltd. MV88SX6041 4-port SATA II PCI-X Controller (rev 03) 6042MV88SX6042 4-port SATA II PCI-X Controller 6081MV88SX6081 8-port SATA II PCI-X Controller - 61016101 SATA2 Controller + 6101MV88SX6101 1-port UltraATA/133 Controller 61116111 SATA2 Controller 61206120 SATA2 Controller 61216121 SATA2 Controller -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
rc.d/mountd: confusing message (and behavior?)
$ /etc/rc.d/mountd onestart /etc/rc.d/mountd: WARNING: /etc/exports is not readable. Exit 1 Actually /etc/exports did not exist at all. And this was not a WARNING, this was a fatal error, mountd did not start. Alsp, should it actually fail like this? I have ZFS and I plan to do all NFS exports from ZFS, so /etc/exports would never be used. -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
[HEADS UP] drm merged to -STABLE
I just merged drm (Direct Rendering) from HEAD. - Support for latest Intel chips - Support and fixes for many AMD/ATI chips r500 and below - Support AMD/ATI IGP based chips (rs690/rs485) - Lots of code cleanups - Lots of other fixes and changes since the existing drm is 2+ years old If you are experiencing a garbled screen with certain pci/pci-e based radeons, I have another patch in HEAD that isn't included yet. thanks, robert. signature.asc Description: This is a digitally signed message part
Re: rc.d/mountd: confusing message (and behavior?)
On Sat, Jan 10, 2009 at 6:20 AM, Andriy Gapon a...@icyb.net.ua wrote:
$ /etc/rc.d/mountd onestart
/etc/rc.d/mountd: WARNING: /etc/exports is not readable.
Exit 1
Actually /etc/exports did not exist at all.
And this was not a WARNING, this was a fatal error, mountd did not start.
Alsp, should it actually fail like this? I have ZFS and I plan to do
all NFS exports from ZFS, so /etc/exports would never be used.
Uh, mountd is used for nfsd, so I'm not sure why you're trying to do
this... The reference to /etc/exports is being picked up from
/etc/rc.d/mountd on this line:
required_files=/etc/exports
and it's picking up the actual `does it exist?' test from:
[gcoo...@orangebox /usr/home/gcooper]$ grep -A 3 required_files /etc/rc.subr
# required_files n If set, check for the readability of the given
# files before running a (re)start command.
#
# required_modules n If set, ensure the given kernel modules are
--
rcvar required_dirs required_files required_vars
eval unset ${_arg}_cmd ${_arg}_precmd ${_arg}_postcmd
case $_file in
--
for _f in $required_files; do
if [ ! -r ${_f} ]; then
warn ${_f} is not readable.
if [ -z $rc_force ]; then
Cheers,
-Garrett
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: rc.d/mountd: confusing message (and behavior?)
on 10/01/2009 17:11 Garrett Cooper said the following:
On Sat, Jan 10, 2009 at 6:20 AM, Andriy Gapon a...@icyb.net.ua wrote:
$ /etc/rc.d/mountd onestart
/etc/rc.d/mountd: WARNING: /etc/exports is not readable.
Exit 1
Actually /etc/exports did not exist at all.
And this was not a WARNING, this was a fatal error, mountd did not start.
Alsp, should it actually fail like this? I have ZFS and I plan to do
all NFS exports from ZFS, so /etc/exports would never be used.
Uh, mountd is used for nfsd, so I'm not sure why you're trying to do
this...
I thought that mountd and nfsd (and rpcbind) are still required even if
exported filesystems are ZFS. Am I wrong on this?
The reference to /etc/exports is being picked up from
/etc/rc.d/mountd on this line:
required_files=/etc/exports
and it's picking up the actual `does it exist?' test from:
[gcoo...@orangebox /usr/home/gcooper]$ grep -A 3 required_files /etc/rc.subr
# required_files n If set, check for the readability of the given
# files before running a (re)start command.
#
# required_modules n If set, ensure the given kernel modules are
--
rcvar required_dirs required_files required_vars
eval unset ${_arg}_cmd ${_arg}_precmd ${_arg}_postcmd
case $_file in
--
for _f in $required_files; do
if [ ! -r ${_f} ]; then
warn ${_f} is not readable.
if [ -z $rc_force ]; then
Cheers,
-Garrett
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: rc.d/mountd: confusing message (and behavior?)
On Sat, Jan 10, 2009 at 7:14 AM, Andriy Gapon a...@icyb.net.ua wrote:
on 10/01/2009 17:11 Garrett Cooper said the following:
On Sat, Jan 10, 2009 at 6:20 AM, Andriy Gapon a...@icyb.net.ua wrote:
$ /etc/rc.d/mountd onestart
/etc/rc.d/mountd: WARNING: /etc/exports is not readable.
Exit 1
Actually /etc/exports did not exist at all.
And this was not a WARNING, this was a fatal error, mountd did not start.
Alsp, should it actually fail like this? I have ZFS and I plan to do
all NFS exports from ZFS, so /etc/exports would never be used.
Uh, mountd is used for nfsd, so I'm not sure why you're trying to do
this...
I thought that mountd and nfsd (and rpcbind) are still required even if
exported filesystems are ZFS. Am I wrong on this?
The reference to /etc/exports is being picked up from
/etc/rc.d/mountd on this line:
required_files=/etc/exports
and it's picking up the actual `does it exist?' test from:
[gcoo...@orangebox /usr/home/gcooper]$ grep -A 3 required_files /etc/rc.subr
# required_files n If set, check for the readability of the given
# files before running a (re)start command.
#
# required_modules n If set, ensure the given kernel modules are
--
rcvar required_dirs required_files required_vars
eval unset ${_arg}_cmd ${_arg}_precmd ${_arg}_postcmd
case $_file in
--
for _f in $required_files; do
if [ ! -r ${_f} ]; then
warn ${_f} is not readable.
if [ -z $rc_force ]; then
Cheers,
-Garrett
Ok, dumb question -- does ZFS offer the same functionality as NFS? I
thought not...
-Garrett
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: rc.d/mountd: confusing message (and behavior?)
Alsp, should it actually fail like this? I have ZFS and I plan to do all NFS exports from ZFS, so /etc/exports would never be used. ZFS writes its own exports file to '/etc/zfs/exports' - as far as I can tell this is pretty much all that happens when you mark a filesystem as NFS shared under ZFS. Then mountd is started from rc like this: /usr/sbin/mountd -r -n /etc/exports /etc/zfs/exports (thats taken from 'ps' on one of my running systems) So you still need an empty /etc/exports to be there. ZFS will take care of managing it's own exports file, but thats all it seems to do - there is no magic ZFS seperate implementation of NFS as far as I know. -pete. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: rc.d/mountd: confusing message (and behavior?)
On Sat, Jan 10, 2009 at 7:24 AM, Garrett Cooper yanef...@gmail.com wrote: On Sat, Jan 10, 2009 at 7:20 AM, Andriy Gapon a...@icyb.net.ua wrote: on 10/01/2009 17:18 Garrett Cooper said the following: s/same functionality/same basic functionality/. Mind you, NFS is a networking filesystem. ZFS is a filestore filesystem, more rooted to the local machine I thought, like UFS. I am well aware of this. The difference between UFS and ZFS is that for the former you have to maintain /etc/exports by hand and for the latter /etc/zfs/exports is automatically managed via zfs tools. Andriy Gapon Maybe a zmountd or equivalent script should be written for zfs and the common code should be factored out for both cases? -Garrett Sorry -- wrong list (current - stable) . -Garrett ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Big problems with 7.1 locking up :-(
FWIW, the other guy I know who is having this problem had already switched to using ULE under 7.0-release, and did not have any problems with it. So *his* problem was probably not related to SCHED_ULE, unless something has recently changed there. Well, one of my machines just locked up again, even with SCHED_4BSD on it, so I am now thinking it is unrelated. The machine has completely locked - no response to pings, no response to keypresses, nor to the power button. There is nothing printed on the console - it is just sitting there with a login prompt :-( This is really not good - these are extremely common servers after all, and I am just running bog standard 7.1 with apache and mysql. This is happening across several different servers, all of which are slight variants on the DL360, so I dont think it is something perculiar to me. -pete. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: [HEADS UP] drm merged to -STABLE
On Sat, 2009-01-10 at 10:01 -0500, Robert Noland wrote: I just merged drm (Direct Rendering) from HEAD. - Support for latest Intel chips - Support and fixes for many AMD/ATI chips r500 and below - Support AMD/ATI IGP based chips (rs690/rs485) - Lots of code cleanups - Lots of other fixes and changes since the existing drm is 2+ years old If you are experiencing a garbled screen with certain pci/pci-e based radeons, I have another patch in HEAD that isn't included yet. I decided to go ahead and fully sync to HEAD, so this should be resolved as well. This added: - Use bus_dma to allocate scatter/gather pages for pci GART. This fixes garbled screen issues on pci based radeons. - Prevent drm from attaching to secondary devices even if they have the the same pci id. robert. thanks, robert. signature.asc Description: This is a digitally signed message part
Re: [HEADS UP] drm merged to -STABLE
On Sat, Jan 10, 2009 at 11:49:01AM -0500, Robert Noland wrote: On Sat, 2009-01-10 at 10:01 -0500, Robert Noland wrote: I just merged drm (Direct Rendering) from HEAD. - Support for latest Intel chips - Support and fixes for many AMD/ATI chips r500 and below - Support AMD/ATI IGP based chips (rs690/rs485) - Lots of code cleanups - Lots of other fixes and changes since the existing drm is 2+ years old If you are experiencing a garbled screen with certain pci/pci-e based radeons, I have another patch in HEAD that isn't included yet. I decided to go ahead and fully sync to HEAD, so this should be resolved as well. This added: - Use bus_dma to allocate scatter/gather pages for pci GART. This fixes garbled screen issues on pci based radeons. - Prevent drm from attaching to secondary devices even if they have the the same pci id. Do cards on the PCIE bus still need the agp device? It seems my r535 (radeon X1650Pro) on the PCIE bus can allocate a GART without it. I have the agp module loaded, but there is no /dev/agpgart device. But if I try to unload the module, it says 'can't unload file: Device busy'. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgplE1fFuEAZp.pgp Description: PGP signature
Re: [HEADS UP] drm merged to -STABLE
On Sat, 2009-01-10 at 18:54 +0100, Roland Smith wrote: On Sat, Jan 10, 2009 at 11:49:01AM -0500, Robert Noland wrote: On Sat, 2009-01-10 at 10:01 -0500, Robert Noland wrote: I just merged drm (Direct Rendering) from HEAD. - Support for latest Intel chips - Support and fixes for many AMD/ATI chips r500 and below - Support AMD/ATI IGP based chips (rs690/rs485) - Lots of code cleanups - Lots of other fixes and changes since the existing drm is 2+ years old If you are experiencing a garbled screen with certain pci/pci-e based radeons, I have another patch in HEAD that isn't included yet. I decided to go ahead and fully sync to HEAD, so this should be resolved as well. This added: - Use bus_dma to allocate scatter/gather pages for pci GART. This fixes garbled screen issues on pci based radeons. - Prevent drm from attaching to secondary devices even if they have the the same pci id. Do cards on the PCIE bus still need the agp device? It seems my r535 (radeon X1650Pro) on the PCIE bus can allocate a GART without it. I have the agp module loaded, but there is no /dev/agpgart device. But if I try to unload the module, it says 'can't unload file: Device busy'. Technically no, pci/pci-e based cards don't need AGP. All of the Intel chips do, as they emulate AGP in all cases. The pci/pci-e radeons do not need AGP at all, but I don't know of a way to conditionally require the AGP module as a dependency in drm. The other issue would be that even if I could, it would probably end up with undefined symbols in drm without agp loaded, even if it isn't used. robert. Roland signature.asc Description: This is a digitally signed message part
Re: [HEADS UP] drm merged to -STABLE
On Saturday 10 January 2009 08:49:01 am Robert Noland wrote: On Sat, 2009-01-10 at 10:01 -0500, Robert Noland wrote: I just merged drm (Direct Rendering) from HEAD. - Support for latest Intel chips - Support and fixes for many AMD/ATI chips r500 and below - Support AMD/ATI IGP based chips (rs690/rs485) - Lots of code cleanups - Lots of other fixes and changes since the existing drm is 2+ years old If you are experiencing a garbled screen with certain pci/pci-e based radeons, I have another patch in HEAD that isn't included yet. I decided to go ahead and fully sync to HEAD, so this should be resolved as well. This added: - Use bus_dma to allocate scatter/gather pages for pci GART. This fixes garbled screen issues on pci based radeons. - Prevent drm from attaching to secondary devices even if they have the the same pci id. What's your plan on incorporating r6xx/r7xx drm :? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
7.1 manpages: first appeared in FreeBSD 8.0
I found a 7.1-RELEASE manpage stating first appeared in FreeBSD 8.0. A little bit of grepping revealed a few more: setfib(1) setfib(2) ffs(3) ffsl(3) ffsll(3) fls(3) flsl(3) flsll(3) memchr(3) memrchr(3) malo(4) crashinfo(8) savecore(8) Some others are correctly stating 7.1 for example textdump(4). Cheers, Jan Henrik ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
vr0: rx packet lost
I'm using 7.0-RELEASE. When there's heavy network traffic through the vr0 interface, I see lots of vr0: rx packet lost messages, and occasional vr0: watchdog timeout messages. I googled and found some information, but it was on an earlier version of FreeBSD, and there weren't any solutions. I didn't load vr as a module, and it's not listed by kldstat, so I assume it was build into the kernel. Ideas? Is there any additional information I should provide? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: [HEADS UP] drm merged to -STABLE
On Sat, 2009-01-10 at 15:53 -0800, vehemens wrote: On Saturday 10 January 2009 08:49:01 am Robert Noland wrote: On Sat, 2009-01-10 at 10:01 -0500, Robert Noland wrote: I just merged drm (Direct Rendering) from HEAD. - Support for latest Intel chips - Support and fixes for many AMD/ATI chips r500 and below - Support AMD/ATI IGP based chips (rs690/rs485) - Lots of code cleanups - Lots of other fixes and changes since the existing drm is 2+ years old If you are experiencing a garbled screen with certain pci/pci-e based radeons, I have another patch in HEAD that isn't included yet. I decided to go ahead and fully sync to HEAD, so this should be resolved as well. This added: - Use bus_dma to allocate scatter/gather pages for pci GART. This fixes garbled screen issues on pci based radeons. - Prevent drm from attaching to secondary devices even if they have the the same pci id. What's your plan on incorporating r6xx/r7xx drm :? The code isn't user ready yet. What AMD has released, I have building. AMD is being quite reasonable about their code, so it won't be a big deal to get that code imported quickly once it is ready. My expectation is that we will ship code, at least in -CURRENT, before any linux distro. ;) robert. ___ freebsd-...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-x11 To unsubscribe, send any mail to freebsd-x11-unsubscr...@freebsd.org signature.asc Description: This is a digitally signed message part
Re: vr0: rx packet lost
At 07:49 PM 1/10/2009, David Ehrmann wrote: I'm using 7.0-RELEASE. Ideas? Is there any additional information I should provide? 7.1R has a *far* better vr driver that has a lot of bug fixes in it. http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/vr/if_vr.c has details of what was fixed. ---Mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Big problems with 7.1 locking up :-(
I noticed a similar problem testing 7.1-RC1, It seemed to be a deep deadlock, as it was triggered by lighttpd doing kern_sendfile, and never returning. The side effects (being unable to create processes, etc) is similar. My kernconf is below, try building the kernel, and send an email containing the backtrace from any process that has blocked (in my case, lighttpd attempting to sendfile a large amount of data to php fastcgi triggered it, but that's a guess on my part). Note that this includes witness, and invariants, so performance will be hit. Also, enable watchdogd, and add -e 'ls -al /etc' to it's flags. It should drop you to a debugger with a backtrace within a few seconds of the lock being triggered, and it should output a backtrace and any invariant/witness lock warnings. Obviously if you don't have a serial or local console, don't do this. include GENERIC ident DEBUG options KDB options DDB options SW_WATCHDOG options DEBUG_VFS_LOCKS options INVARIANTS options WITNESS On 1/10/09, Pete French petefre...@ticketswitch.com wrote: FWIW, the other guy I know who is having this problem had already switched to using ULE under 7.0-release, and did not have any problems with it. So *his* problem was probably not related to SCHED_ULE, unless something has recently changed there. Well, one of my machines just locked up again, even with SCHED_4BSD on it, so I am now thinking it is unrelated. The machine has completely locked - no response to pings, no response to keypresses, nor to the power button. There is nothing printed on the console - it is just sitting there with a login prompt :-( This is really not good - these are extremely common servers after all, and I am just running bog standard 7.1 with apache and mysql. This is happening across several different servers, all of which are slight variants on the DL360, so I dont think it is something perculiar to me. -pete. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: vr0: rx packet lost
On Sat, Jan 10, 2009 at 08:51:06PM -0500, Mike Tancsa wrote: At 07:49 PM 1/10/2009, David Ehrmann wrote: I'm using 7.0-RELEASE. Ideas? Is there any additional information I should provide? 7.1R has a *far* better vr driver that has a lot of bug fixes in it. http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/vr/if_vr.c has details of what was fixed. As Mike said several known bugs were fixed. If you still see problems on 7.1-RELEASE, let me know. -- Regards, Pyun YongHyeon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: vr0: rx packet lost
Wow. That really is a lot, but I might just wait for the final release, though with this command, it might not be such a big deal: freebsd-update upgrade -r 7.1-RC1 Mike Tancsa wrote: At 07:49 PM 1/10/2009, David Ehrmann wrote: I'm using 7.0-RELEASE. Ideas? Is there any additional information I should provide? 7.1R has a *far* better vr driver that has a lot of bug fixes in it. http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/vr/if_vr.c has details of what was fixed. ---Mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: vr0: rx packet lost
On 2009-Jan-10 19:15:22 -0800, David Ehrmann ehrm...@gmail.com wrote: Wow. That really is a lot, but I might just wait for the final release, though with this command, it might not be such a big deal: freebsd-update upgrade -r 7.1-RC1 FreeBSD 7.1-RELEASE has been available for nearly a week. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgp3TpPLsRLGi.pgp Description: PGP signature
