How to change kernel version tag?
Hi all. Could I change the kernel version tag manually? say, I have a kernel which is 7.0-CUREENT, but for some reasons I wanna it be something like 6.1-RELEASE, while the kernel itself does't change from 7.0-CURRENT to 6.1-RELEASE. All I want is the change of tag. For example, if this works, then when I type "uname -a" in console, I would get "6.1-RELEASE ..." instead of "7.0-CURRENT ...". I guess some config files in src/sys/ could take care of this. But I cannot find it out. Anybody knows how to get this job done? Any ideas are really appreciated. :-) BTW: I am not in this list. So if you reply, please CC a copy to me. Thanks. -- Best Regards Yuan, Jue @ http://www.yuanjue.net ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How to change kernel version?
Yuan, Jue wrote: Hi all. Could I change the kernel version tag manually? say, I have a kernel which is 7.0-CUREENT, but for some reasons I wanna it be something like 6.1-RELEASE, while the kernel itself does't change from 7.0-CURRENT to 6.1-RELEASE. All I want is the change of tag. For example, if this works, then when I type "uname -a" in console, I would get "6.1-RELEASE ..." instead of "7.0-CURRENT ...". I guess some config files in src/sys/ could take care of this. But I cannot find it out. Anybody knows how to get this job done? Any ideas are really appreciated. :-) BTW: I am not in this list. So if you reply, please CC a copy to me. Thanks. -- Best Regards Yuan, Jue @ http://www.yuanjue.net ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]" /sys/conf/newvers.sh Modify it at your own risk. From Beijing, China ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How to change kernel version tag?
Yuan, Jue wrote: Hi all. Could I change the kernel version tag manually? say, I have a kernel which is 7.0-CUREENT, but for some reasons I wanna it be something like 6.1-RELEASE, while the kernel itself does't change from 7.0-CURRENT to 6.1-RELEASE. All I want is the change of tag. For example, if this works, then when I type "uname -a" in console, I would get "6.1-RELEASE ..." instead of "7.0-CURRENT ...". You jast want to change the uname output, or some software checks kernel version? rik I guess some config files in src/sys/ could take care of this. But I cannot find it out. Anybody knows how to get this job done? Any ideas are really appreciated. :-) BTW: I am not in this list. So if you reply, please CC a copy to me. Thanks. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [PATCH] adding two new options to 'cp'
On Thursday 24 August 2006 16:45, Julian Elischer wrote: > Eric Anderson wrote: > > > On 08/20/06 04:21, Mike Silbersack wrote: > > > >> On Wed, 26 Jul 2006, Eric Anderson wrote: > >> > >>> I'm tired of trying to use rsync or gcp (which doesn't like symlinks > >>> often) to copy trees of files/directories using hard links, so I > >>> added the gcp-ish options -a and -l. > >> > >> > >> ... > >> > >>> Comments? Flames? Committers willing to commit? > >>> > >>> Eric > >> > >> > >> Having just read this thread start to finish, I strongly feel that > >> Eric should be given an award for putting up with all the crap he was > >> given and not losing his temper. > >> > >> In sincerely hope that this thread does not scare off others who have > >> local patches that they are considering contributing to FreeBSD. > >> > >> Mike "Silby" Silbersack > > > > > > > > Alas, no parts of my patch ever were committed. :( > > > > *sigh* - off to other hacking.. > > > > Eric > > > > > Add an option to allow copying of a hierarchy while linking he regular > files. > Bikeshedded to death on: hackers > Submitted by:andersonatcenttech.com > MFC in: 1 month It was on my todo list as well. I think I'll still add the -a option. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: global data via module howto
Hi,
I've done it. Thanks for the road map.
M. Warner Losh wrote:
In message: <[EMAIL PROTECTED]>
Roman Kurakin <[EMAIL PROTECTED]> writes:
: M. Warner Losh wrote:
: > In message: <[EMAIL PROTECTED]>
: > Roman Kurakin <[EMAIL PROTECTED]> writes:
: > : I have the following problem:
: > : module A
: > : int x;
: > :
: > : module B
: > : extern int x;
: > :
: > : Module A is loaded, module B can't be loaded cause of unknow 'x'.
: > : What should I do to make x global?
: >
: > Better to make module B depend on module A. Making it global is
: > generally a bad idea.
: >
: > in module A:
: > MODULE_VERSION(A, 1);
: >
: > In module B:
: > MODULE_DEPEND(B, A, 1, 1, 1);
: >
: Module dependence is not the goal.
Right. That's how symbols are visible to other modules.
Yes, it works. And it is still needed for class/subclass scheme.
: >
: > : PS. I am working on porting irda support for USB devices from NetBSD.
: > : The current model consists of two layers hw and sw. hw is the usb device
: > : driver. sw is some software layer the same for all device and it is a
: > : child on top of hw 'bus'. To make this working I need to add
: > : DRIVER_MODULE for each 'bus'. To make sw independent from the
: > : bus I need to export _driver and _class structures and put DRIVER_MODULE
: > : in 'bus' code instead of 'child'.
: >
: > Are you sure that you need to do this? I'm pretty sure that you can
: > create a base class irdabus and then derive all the hw modules that
: > implement irdabus from than and all the children will automatically
: > probe. No need to export the driver/class structures.
This was a bit wrong. You still need to export kobj_class (eq driver_t
structure,
DECLARE_CLASS).
: >
: I have a bit reversed case. In common case we have a driver for "bus"
: with many
: consumers. And we have children that declares itself via DRIVER_MODULE.
: If child could work on several buses it declares itself several times
: one for each
: bus. In my case I have several drivers that could be treated as bus
: driver for the
: same child:
:
: ---USB
: || |
: ustir uirda smth_else
: \| /
: -irframe
:
: Imagine, if the network interface was implemented as a child of every
: network
: adapter. This is the same. In common case I'll put DRIVER_MODULE in a child
: for each bus and recompile after adding a new one. In this case I do no
: want to
: recompile the child for every new "bus" since child do not depend on
: such "bus"
: - it is the same for all. So we may call this a pseudo-device with
: unknown list
: of buses. I know, I could implement this other way, but I just want to
: play with
: newbus a bit and the original NetBSD driver was implemented this way.
I think I must have not been clear before. I thought gave a solution
to this that doesn't require a new DRIVER_MODULE for each new device.
Let me try again.
I'd hoped to say make ustir, uirda and smth_else all subclasses of a
irbridge class, just like we do for pci and cardbus today. Then
irframe would attach to irbridge and you'd only need to list
DRIVER_MODULE lines once. This isn't a reversed case at all. It is
actually quite common, but has been 'papered over' until now via
multiple DRIVER_MODULE lines, except in the case of pci/cardbus[*].
I can provide more details on actually doing this. Right now I'm
doing something similar for all the iic bridges that we have in the
kernel. The number of devices with iicbus children is way too large
and we can eliminate that issue via the technique. I'd be happy to
flesh it out a bit, or provide you with sample code if you need that.
For curious:
==irda_bus==
static device_probe_t irda_bus_probe;
static device_attach_t irda_bus_attach;
static device_detach_t irda_bus_detach;
static device_method_t irda_bus_methods[] = {
/* stub functions */
DEVMETHOD(device_probe, irda_bus_probe), /* aka match */
DEVMETHOD(device_attach, irda_bus_attach),
DEVMETHOD(device_detach, irda_bus_detach),
{0,0}
};
struct irda_bus_softc {
};
MODULE_VERSION(irda_bus, 1);
DEFINE_CLASS_0(irda_bus, irda_bus_driver, irda_bus_methods,
sizeof(struct irda_bus_softc));
===
ustir
Static device_probe_t ustir_match;
Static device_attach_t ustir_attach;
Static device_detach_t ustir_detach;
Static devclass_t ustir_devclass;
Static device_method_t ustir_methods[] = {
DEVMETHOD(device_probe, ustir_match),
DEVMETHOD(device_attach, ustir_attach),
DEVMETHOD(device_detach, ustir_detach),
{0,0}
};
MODULE_DEPEND(ustir, usb, 1, 1, 1);
MODULE_DEPEND(ustir, irda_bus, 1, 1, 1);
DECLARE_CLASS(irda_bus_driver);
DEFINE_CLASS_1(irda_bus, ustir_driver, ustir_methods,
sizeof(struct ustir_softc), irda_bus_driver);
DRIVER_MODULE(ustir,
Re: How to change kernel version?
On Friday 25 August 2006 22:02, Intron is my alias on the Internet wrote: > Yuan, Jue wrote: > > Hi all. > > > > Could I change the kernel version tag manually? say, I have a kernel > > which is 7.0-CUREENT, but for some reasons I wanna it be something like > > 6.1-RELEASE, while the kernel itself does't change from 7.0-CURRENT to > > 6.1-RELEASE. All I want is the change of tag. For example, if this works, > > then when I type "uname -a" in console, I would get "6.1-RELEASE ..." > > instead of "7.0-CURRENT ...". > > /sys/conf/newvers.sh > > Modify it at your own risk. > Thanks very much. That is exactly what I want, although I have found another way to solve my problem. :-) -- Best Regards Yuan, Jue @ http://www.yuanjue.net ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How to change kernel version tag?
On Friday 25 August 2006 22:32, Roman Kurakin wrote: > Yuan, Jue wrote: > > Hi all. > > > > Could I change the kernel version tag manually? say, I have a kernel > > which is 7.0-CUREENT, but for some reasons I wanna it be something like > > 6.1-RELEASE, while the kernel itself does't change from 7.0-CURRENT to > > 6.1-RELEASE. All I want is the change of tag. For example, if this works, > > then when I type "uname -a" in console, I would get "6.1-RELEASE ..." > > instead of "7.0-CURRENT ...". > > You jast want to change the uname output, or some software checks kernel > version? > I think the uname output is enough. I have found __FreeBSD_version in /sys/sys/param.h, and was told the file /sys/conf/newvers.sh. So I guess the problem has already solved. :-) Anyway, thanks all the same. -- Best Regards Yuan, Jue @ http://www.yuanjue.net ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [PATCH] adding two new options to 'cp'
At 9:05 AM -0400 8/25/06, John Baldwin wrote: On 24 August 2006, Julian Elischer wrote in a cvs-commit log: > > Add an option to allow copying of a hierarchy while > linking he regular files. Very good for commiting this -- except that I'm not quite sure that log-message is parseable! From looking at the man-page update, this option only handles hard-links? What happens with symlinks? > Bikeshedded to death on: hackers Submitted by:andersonatcenttech.com MFC in: 1 month It was on my todo list as well. I think I'll still add the -a option. I think that is a good idea, too. -- Garance Alistair Drosehn = [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Institute; Troy, NY; USA ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Latest patch for PPP
Hello,
in the latest security advisory for PPP, the patch deals with conditions
in a for loop. The correct line is :
for (rlen=0; len >= 2 && p[1] >= 2 && len >= p[1]; len-=p[1], p+=p[1]) {
Couldn't the condition be simpler like :
for (rlen=0; p[1] >= 2 && len >= p[1]; len-=p[1], p+=p[1]){
Or is there a hack I didn't understand ?
In this case, if p[1] is greater or equal than 2, if we ensure that len
>= p[1], we don't have to test that it's greater or equal than 2, isn't
>it ?
Fred
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
momentary system "pauses" when switching VTYs
Hello. I did a stock install of 6.1-RELEASE yesterday and I noticed something weird. Whenever I switched the virtual console to a different screen, it would take almost 2 whole seconds before switching. At first I thought it was IRQ related since it was happening during the heavy disk activity of an install, but I noticed the same behavior after rebooting the machine. I csup'd to RELENG_6 as of last night and that didn't help. One thing I did notice is that the whole kernel seems to "pause" during the two second switching operation-- I noticed this because I switched virtual screens during a bg fsck and each time I switched, the ATA light would turn off during the duration and come back on immediately after the console switched. This behavior is 100% repeatable for me. I looked at "systat -vms" and top(1) but didn't notice anything out of the ordinary. This only seems to affect this one system; my other machines switch virtual screens instantly. This happened both with GENERIC and SMP kernels.. I'll include the latest dmesg below. Nothing else appeared in any logs. I can provide a verbose dmesg if necessary. The only thing I can think of is that I'm using kbdmux with no PS/2 keyboard attached-- but I'm using a similar USB keyboard on another 6.1-STABLE box just fine. Any ideas? -- Rick C. Petty output of dmesg: Copyright (c) 1992-2006 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 6.1-STABLE #0: Fri Aug 25 01:16:11 CDT 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC module_register: module uhub/ums already exists! Module uhub/ums failed to register: 17 mptable_probe: MP Config Table has bad signature: 4\^C\^_ ACPI APIC Table: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Sempron(tm) 2500+ (1746.83-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x681 Stepping = 1 Features=0x383fbff AMD Features=0xc0480800 real memory = 1610547200 (1535 MB) avail memory = 1569087488 (1496 MB) ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 ath_hal: 0.9.17.2 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) 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_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 Correcting nForce2 C1 CPU disconnect hangs agp0: mem 0xc000-0xcfff at device 0.0 on pci0 pci0: at device 0.1 (no driver attached) pci0: at device 0.2 (no driver attached) pci0: at device 0.3 (no driver attached) pci0: at device 0.4 (no driver attached) pci0: at device 0.5 (no driver attached) isab0: at device 1.0 on pci0 isa0: on isab0 pci0: at device 1.1 (no driver attached) ohci0: mem 0xde086000-0xde086fff irq 20 at device 2.0 on pci0 ohci0: [GIANT-LOCKED] usb0: OHCI version 1.0, legacy support usb0: SMM does not respond, resetting usb0: on ohci0 usb0: USB revision 1.0 uhub0: nVidia OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 3 ports with 3 removable, self powered ohci1: mem 0xde081000-0xde081fff irq 21 at device 2.1 on pci0 ohci1: [GIANT-LOCKED] usb1: OHCI version 1.0, legacy support usb1: SMM does not respond, resetting usb1: on ohci1 usb1: USB revision 1.0 uhub1: nVidia OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 3 ports with 3 removable, self powered ehci0: mem 0xde082000-0xde0820ff irq 22 at device 2.2 on pci0 ehci0: [GIANT-LOCKED] usb2: EHCI version 1.0 usb2: companion controllers, 4 ports each: usb0 usb1 usb2: on ehci0 usb2: USB revision 2.0 uhub2: nVidia EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub2: 6 ports with 6 removable, self powered nve0: port 0xe400-0xe407 mem 0xde083000-0xde083fff irq 20 at device 4.0 on pci0 nve0: Ethernet address 00:11:2f:e4:95:b4 miibus0: on nve0 rlphy0: on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto nve0: Ethernet address: 00:11:2f:e4:95:b4 pci0: at device 5.0 (no driver attached) pcm0: port 0xd000-0xd0ff,0xd400-0xd47f mem 0xde087000-0xde087fff irq 22 at device 6.0 on pci0 pcm0: pcib1: at device 8.0 on pci0 pci1: on pcib1 skc0: port 0xa000-0xa0ff mem 0xdd00-0xdd003fff irq 17 at device 4.0 on pci1 skc0: Marvell Yukon Lite Gigabit Ethernet rev. A3(0x7) sk0: on skc0 sk0: Ethernet address: 00:11:2f:e4:85:7e miibus1: on sk0 e1000phy0: on miibus1 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX, auto pci1: at device 6.0 (no driver attached) pci1: at device 6.1 (no driver attached) atapci0: port 0xa400-0xa407,0xa800-0xa803,0xac00-0xac07,0xb000-0xb003,0xb400-0xb40f mem 0xdd004000-0xdd0041ff irq 18 at device 11.0 on pci1 ata2: on atapci0 ata3: on atapci0 atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xf000-0xf00f at device 9.0 on pci0 ata0: on atapci1 ata1: on atapci1 fwohci0: <1394 Open Host Control
Re: [PATCH] adding two new options to 'cp'
On 08/25/06 11:49, Garance A Drosehn wrote: At 9:05 AM -0400 8/25/06, John Baldwin wrote: On 24 August 2006, Julian Elischer wrote in a cvs-commit log: > > Add an option to allow copying of a hierarchy while > linking he regular files. Very good for commiting this -- except that I'm not quite sure that log-message is parseable! From looking at the man-page update, this option only handles hard-links? What happens with symlinks? No change in functionality - copies them like it normally would (depending on what other options you may have used). It doesn't try to hard link them if that is what you are asking. > Bikeshedded to death on: hackers Submitted by:andersonatcenttech.com MFC in: 1 month It was on my todo list as well. I think I'll still add the -a option. I think that is a good idea, too. Eric -- Eric AndersonSr. Systems AdministratorCentaur Technology Anything that works is better than anything that doesn't. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Latest patch for PPP
Frederic Praca:
Hello,
in the latest security advisory for PPP, the patch deals with conditions
in a for loop. The correct line is :
for (rlen=0; len >= 2 && p[1] >= 2 && len >= p[1]; len-=p[1], p+=p[1]) {
Couldn't the condition be simpler like :
for (rlen=0; p[1] >= 2 && len >= p[1]; len-=p[1], p+=p[1]){
If len<2 you just can't access (theoretically) p[1] cause in best case
you have only p[0] (len=1)
or do not have even p[0] (len=0). So from general point of view this is
correct code.
rik
Or is there a hack I didn't understand ?
In this case, if p[1] is greater or equal than 2, if we ensure that len
= p[1], we don't have to test that it's greater or equal than 2, isn't
it ?
Fred
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
fsync: giving up on dirty
I got this error today, while some very heavy disk access was occurring: Aug 25 13:47:07 snapshot1 kernel: fsync: giving up on dirty Aug 25 13:47:07 snapshot1 kernel: 0xff01bbb99a20: tag devfs, type VCHR Aug 25 13:47:07 snapshot1 kernel: usecount 1, writecount 0, refcount 445 mountedhere 0xff023ee20800 Aug 25 13:47:07 snapshot1 kernel: flags () Aug 25 13:47:07 snapshot1 kernel: v_object 0xff01c34afb60 ref 0 pages 16386 Aug 25 13:47:07 snapshot1 kernel: lock type devfs: EXCL (count 1) by thread 0xff023f11d980 (pid 46)#0 0x803eeaa6 at lockmgr+0x5f6 Aug 25 13:47:07 snapshot1 kernel: #1 0x8065e8d1 at VOP_LOCK_APV+0x81 Aug 25 13:47:07 snapshot1 kernel: #2 0x8047015b at vn_lock+0x6b Aug 25 13:47:07 snapshot1 kernel: #3 0x805719be at ffs_sync+0x1fe Aug 25 13:47:07 snapshot1 kernel: #4 0x80472045 at vfs_write_suspend+0x95 Aug 25 13:47:07 snapshot1 kernel: #5 0x80b794a5 at g_journal_switcher+0xa55 Aug 25 13:47:07 snapshot1 kernel: #6 0x803e3cdb at fork_exit+0xbb Aug 25 13:47:07 snapshot1 kernel: #7 0x805f39ce at fork_trampoline+0xe Aug 25 13:47:07 snapshot1 kernel: Aug 25 13:47:07 snapshot1 kernel: dev label/vol11-data.journal Aug 25 13:47:07 snapshot1 kernel: GEOM_JOURNAL: Cannot suspend file system /vol11 (error=35). Eric -- Eric AndersonSr. Systems AdministratorCentaur Technology Anything that works is better than anything that doesn't. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: doadump at pcpu.h:165
On Thu, 2006-Aug-24 17:39:56 +0200, Daniel A. wrote: >My server crashes very often and it's very random. ... >panic: machine check trap ... >As far as I understand, the issue is CPU-related, but that doesn't make >sense, as my network interface cards are constantly giving me watchdog >timeouts. This sounds like flaky hardware. Try checking cooling, PSU, RAM, cabling socketing etc. Run memtest86 or similar and try swapping components. -- Peter Jeremy pgpDkIzeysmng.pgp Description: PGP signature
