Re: "ide=reverse" do we still need this?
On Tue, Feb 12, 2008 at 04:15:07PM -0800, Greg KH wrote: > > I'm curious if we really still support the ide=reverse option? It's a > config option that I don't think the distros still enable (SuSE does > not). Is this still needed these days? > My "server" has a consumer-grade desktop amd64 mobo, with all that implies about cheap hardware and strange/misleading bios options. It also has an add-in dual IDE card with the main data on raid1. It's set to ide=reverse, without that it doesn't boot (the add-ins are IDE, system drive is SATA, so I guess it probably tries to boot from the DVD - it's been a long time since it bit me and I don't remember the full details. That was how it was set for 2.6.18.6, and how it now boots from 2.6.22.18. I think at one time the order of the interfaces might have been different. Certainly, I carry forward a fallback without ide=reverse in lilo.conf, just in case the disks move on my next kernel upgrade. What a distro selects should cover most of that distro's users, but that is not anywhere near providing 100% coverage for *all* the hardware out there. Also, you can force your users to e.g. mount by label. So far, that hasn't been forced on me, and I really hate having to reboot that box :) Ken -- das eine Mal als Tragödie, das andere Mal als Farce -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: "ide=reverse" do we still need this?
On Tue, Feb 12, 2008 at 08:43:04PM -0800, Greg KH wrote: > > Can't you just boot with /dev/disk/by-id/ and an initramfs to not have > to worry about such a thing in the future? > Can comebody remind me what the initramfs is for in that situation, please ? From the little I've noticed, I thought the /dev/disk/by-id part went into fstab ? At the moment, I just build the things I think I need in to the kernel on that box, without modules. Anyway, I'll try to find time to read my notes to see if I can identify what happened/when, and to take the box down again so I can try to confirm exactly what the problem is, if it still exists. I certainly won't be taking it down until I've written my weekly backups to tape at the weekend, so maybe not before next week. > Have you tried the PATA drivers instead of IDE to see if this solves the > "moves around" issue? If they work, then you would not need the command > line option at all. My previous kernel was 2.18-series, I think at that time they were still under development. This box handles the backups for my various desktop boxes, which is why I'm very conservative about changing it. I guess the drivers are stable now, I'll maybe give that a go (depending on time). Ken -- das eine Mal als Tragödie, das andere Mal als Farce -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Console font corruption on tty1 after using xorg in 3.6 with i915
Hi, since 3.6-rc7 I'm *sometimes* seeing console font corruption on tty1 after I leave xorg [ I'm old enough to use 'startx' ]. This is with a 512-glyph font. What seems to be happening is that many lower-case ASCII letters, and also '0', are replaced by other glyphs. Many of these other glyphs happen to be stored at ASCII values below 'space' in my font, but I doubt that is important. Last week I tried to determine where/when this happened, and managed to get it by using the 3.4 epiphany browser, perhaps only when accessing googlemail. But it didn't happen all the time. I never saw it with 3.6-rc3, but I did see it with all of -rc7, 3.6.0, 3.6.1. I then upgraded to 3.6.3 and the problem seemed to have gone. Unfortunately, tonight it happened again in 3.6.3. Is anyone else seeing anything like this ? Just to be clear, I normally log in on tty1. If the problem occurs, tty2 to tty6 are fine. The only way I've found to fix the corruption is to reboot. I'm mentioning i915 in the subject because my r600 radeon doesn't have this problem. ken -- das eine Mal als Tragödie, das andere Mal als Farce -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
r8169 on 3.8.13, 3.9.2, 3.10-rc1, was Re: [ 00/73] 3.8.13-stable review
On Fri, May 10, 2013 at 12:54:27PM +0200, Holger Hoffstaette wrote: Cc'ing to netdev because I don't think this has had a response, and I care because I *might* be seeing the same problem on both 3.9.2 and 3.10-rc1, but my take on the problem is slightly different [ details after Holger's posting ] > On Thu, 09 May 2013 15:31:23 -0700, Greg Kroah-Hartman wrote: > > > This is the start of the stable review cycle for the 3.8.13 release. There > > This patchset broke my internet, with all sorts of weird effects like > Samba clients having problems to talk to the server and only partially > working DNS resolution (CDNs broken, Amazon unreachable). > > After two reboots to/from .12/.13 (to rule out temporary internet > brokenness) the problem has been identified as: > > > Stefan Bader > > r8169: fix 8168evl frame padding. > > After reverting only this patch (turning r8169 back to 3.8.12) things > again behave as expected with the rest of .13. So far no other regressions > detected. > > This patch should probably be removed from 3.9.2-rc as well. > > -h > For me, I'm seeing what might be a similar problem in about 2/5 of my boots of 3.9.2 and 3.10-rc1 : in my case, r8169 is a module [ most things are built in ], I use dhclient to get an ip address, and I have separate nfs shares for /sources [ in /etc/mtab ] and my user's ~/notes [ mounted from ~/.bashrc ]. On a good boot, everything mounts. On a bad boot, /sources is NOT mounted because eth0 is not up, but by the time anyone logs in it _is_ up so mounting ~/notes [and manually mounting /sources as root] works. What seems to be happening is that eth0 is coming up slightly later on some occasions (about 11 seconds from booting, instead of 10.5 seconds) and somehow the dhclient script seems to have ended *before* that. For me, this isn't bisectable (so far, 10 boots of 3.9.2 and 3.10-rc1 on this box, and 4 were problematic). On this box, 3.9.0 itself was perfect. Holger : apologies if I've hijacked this thread with what turns out to be a different problem. ken -- das eine Mal als Tragödie, das andere Mal als Farce -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: r8169 on 3.8.13, 3.9.2, 3.10-rc1, was Re: [ 00/73] 3.8.13-stable review
On Wed, May 15, 2013 at 08:14:01AM +0200, Francois Romieu wrote: > Ken Moffat : > [...] > > Cc'ing to netdev because I don't think this has had a response, and > > A patch has been sent to netdev a few hours ago. It needs more work, > especially testing (hint, hint) as I don't have a proven test case yet. > > Please note: > - if you don't use a 8168evl (check your dmesg for the XID line emitted > by the r8169 driver), you are not the experiencing the same bug. [3.174180] r8169 :02:00.0 eth0: RTL8168evl/8111evl at 0xc9008000, c8:60:00:97:07:35, XID 0c900800 IRQ 41 > - if you don't enable Tx checksum offload (distro/vendor dependent though > disabled by default in the vanilla driver, see ethtool -k eth0, > ethtool -K eth0 tx on sg on)), you are not the experiencing the same > bug. If it is disabled by default then my problem is different (I don't have an ethtool program) > - if you are experiencing the same bug, 3.10-rc1 should work again > after reverting e5195c1f31f399289347e043d6abf3ffa80f0005 > > If someone comes with a failing network capture and a working one, it will > save time. A 64 bytes (max) packet is not correctly transmitted. > > -- > Ueimor Thanks for the detailed comments, looks as if my intermittent problem is something else. ken -- das eine Mal als Tragödie, das andere Mal als Farce -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [libata] Fix HDIO_DRIVE_CMD ioctl sense data check
On Wed, Apr 03, 2013 at 07:49:48PM -0400, Jeff Garzik wrote: > > applied the version from Krzysztof Mazur, which covered both cases > > According to linus's changelog for -rc6, this doesn't seem to have been included ? ken -- das eine Mal als Tragödie, das andere Mal als Farce -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
smartd broken in 3.9.0-rc4
Hi, just tested my first 3.9 kernel today. During boot, smartd (from smartmontools-6.0) fails to start. Works fine in 3.8.4. In 3.8.4 I get messages like this : Mar 27 22:02:02 ac4tv smartd[3981]: smartd 6.0 2012-10-10 r3643 [x86_64-linux-3.8.4] (local build) Mar 27 22:02:02 ac4tv smartd[3981]: Copyright (C) 2002-12, Bruce Allen, Christian Franke, www.smartmontools.org Mar 27 22:02:02 ac4tv smartd[3981]: Opened configuration file /etc/smartd.conf Mar 27 22:02:02 ac4tv smartd[3981]: Configuration file /etc/smartd.conf parsed. Mar 27 22:02:02 ac4tv smartd[3981]: Device: /dev/sda, opened Mar 27 22:02:02 ac4tv smartd[3981]: Device: /dev/sda, WDC WD5000AAKX-001CA0, S/N:WD-WMAYU6818967, WWN:5-0014ee-0ad9caed4, FW:15.01H15, 500 GB Mar 27 22:02:02 ac4tv smartd[3981]: Device: /dev/sda, found in smartd database: Western Digital Caviar Blue Serial ATA Mar 27 22:02:02 ac4tv smartd[3981]: Device: /dev/sda, enabled SMART Automatic Offline Testing. Mar 27 22:02:02 ac4tv smartd[3981]: Device: /dev/sda, is SMART capable. Adding to "monitor" list. Mar 27 22:02:02 ac4tv smartd[3981]: Monitoring 1 ATA and 0 SCSI devices but in 3.9.0-rc4 all I get is Mar 28 00:39:32 ac4tv smartd[2487]: Copyright (C) 2002-12, Bruce Allen, Christian Franke, www.smartmontools.org Mar 28 00:39:32 ac4tv smartd[2487]: Opened configuration file /etc/smartd.conf Mar 28 00:39:32 ac4tv smartd[2487]: Configuration file /etc/smartd.conf parsed. Mar 28 00:39:32 ac4tv smartd[2487]: Device: /dev/sda, opened Mar 28 00:39:32 ac4tv smartd[2487]: Device: /dev/sda, WDC WD5000AAKX-001CA0, S/N:WD-WMAYU6818967, WWN:5-0014ee-0ad9caed4, FW:15.01H15, 500 GB Mar 28 00:39:32 ac4tv smartd[2487]: Device: /dev/sda, found in smartd database: Western Digital Caviar Blue Serial ATA Mar 28 00:39:32 ac4tv smartd[2487]: Device: /dev/sda, could not enable SMART capability Mar 28 00:39:32 ac4tv smartd[2487]: Unable to register ATA device /dev/sda at line 1 of file /etc/smartd.conf Mar 28 00:39:32 ac4tv smartd[2487]: Unable to register device /dev/sda (no Directive -d removable). Exiting. Using strace, in the failing version I get 2643 ioctl(3, HDIO_DRIVE_CMD, 0x7fff53288a60) = -1 EIO (Input/output error) instead of the normal 3981 ioctl(3, HDIO_DRIVE_CMD, 0x7fff04437340) = 0 3981 ioctl(3, HDIO_DRIVE_TASK, 0x7fff04437350) = 0 3981 ioctl(3, HDIO_DRIVE_CMD, 0x7fff04437330) = 0 3981 ioctl(3, HDIO_DRIVE_CMD, 0x7fff04437330) = 0 3981 ioctl(3, HDIO_DRIVE_TASK, 0x7fff04437340) = 0 Looks like I'll be bisecting. ken -- das eine Mal als Tragödie, das andere Mal als Farce -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: smartd broken in 3.9.0-rc4 : bisected
On Thu, Mar 28, 2013 at 01:01:48AM +, Ken Moffat wrote: Adding Cc:s, further details at the end. > Hi, > > just tested my first 3.9 kernel today. During boot, smartd (from > smartmontools-6.0) fails to start. Works fine in 3.8.4. > > In 3.8.4 I get messages like this : > > Mar 27 22:02:02 ac4tv smartd[3981]: smartd 6.0 2012-10-10 r3643 > [x86_64-linux-3.8.4] (local build) > Mar 27 22:02:02 ac4tv smartd[3981]: Copyright (C) 2002-12, Bruce > Allen, Christian Franke, www.smartmontools.org > Mar 27 22:02:02 ac4tv smartd[3981]: Opened configuration file > /etc/smartd.conf > Mar 27 22:02:02 ac4tv smartd[3981]: Configuration file > /etc/smartd.conf parsed. > Mar 27 22:02:02 ac4tv smartd[3981]: Device: /dev/sda, opened > Mar 27 22:02:02 ac4tv smartd[3981]: Device: /dev/sda, WDC > WD5000AAKX-001CA0, S/N:WD-WMAYU6818967, WWN:5-0014ee-0ad9caed4, > FW:15.01H15, 500 GB > Mar 27 22:02:02 ac4tv smartd[3981]: Device: /dev/sda, found in > smartd database: Western Digital Caviar Blue Serial ATA > Mar 27 22:02:02 ac4tv smartd[3981]: Device: /dev/sda, enabled SMART > Automatic Offline Testing. > Mar 27 22:02:02 ac4tv smartd[3981]: Device: /dev/sda, is SMART > capable. Adding to "monitor" list. > Mar 27 22:02:02 ac4tv smartd[3981]: Monitoring 1 ATA and 0 SCSI > devices > > but in 3.9.0-rc4 all I get is > Mar 28 00:39:32 ac4tv smartd[2487]: Copyright (C) 2002-12, Bruce > Allen, Christian Franke, www.smartmontools.org > Mar 28 00:39:32 ac4tv smartd[2487]: Opened configuration file > /etc/smartd.conf > Mar 28 00:39:32 ac4tv smartd[2487]: Configuration file > /etc/smartd.conf parsed. > Mar 28 00:39:32 ac4tv smartd[2487]: Device: /dev/sda, opened > Mar 28 00:39:32 ac4tv smartd[2487]: Device: /dev/sda, WDC > WD5000AAKX-001CA0, S/N:WD-WMAYU6818967, WWN:5-0014ee-0ad9caed4, > FW:15.01H15, 500 GB > Mar 28 00:39:32 ac4tv smartd[2487]: Device: /dev/sda, found in > smartd database: Western Digital Caviar Blue Serial ATA > Mar 28 00:39:32 ac4tv smartd[2487]: Device: /dev/sda, could not > enable SMART capability > Mar 28 00:39:32 ac4tv smartd[2487]: Unable to register ATA device > /dev/sda at line 1 of file /etc/smartd.conf > Mar 28 00:39:32 ac4tv smartd[2487]: Unable to register device > /dev/sda (no Directive -d removable). Exiting. > > Using strace, in the failing version I get > 2643 ioctl(3, HDIO_DRIVE_CMD, 0x7fff53288a60) = -1 EIO (Input/output error) > > instead of the normal > 3981 ioctl(3, HDIO_DRIVE_CMD, 0x7fff04437340) = 0 > 3981 ioctl(3, HDIO_DRIVE_TASK, 0x7fff04437350) = 0 > 3981 ioctl(3, HDIO_DRIVE_CMD, 0x7fff04437330) = 0 > 3981 ioctl(3, HDIO_DRIVE_CMD, 0x7fff04437330) = 0 > 3981 ioctl(3, HDIO_DRIVE_TASK, 0x7fff04437340) = 0 > > Looks like I'll be bisecting. > > ken Bisection blames : commit 84a9a8cd9d0aa93c17e5815ab8a9cc4c0a765c63 Author: Gwendal Grignou Date: Fri Jan 18 10:56:43 2013 -0800 [libata] Set proper SK when CK_COND is set. When the user application sends a ATA_12 or ATA_16 PASSTHROUGH scsi command, put the task file register in the sense data with the proper Sense Key. Instead of NO SENSE, set RECOVERED, as specified in [SAT2]12.2.5 Table 92. That reverts cleanly from 3.9.0-rc4, and with it reverted smartd works again. Obviously that does nothing to fix whatever problem this was supposed to fix. I can test any follow-up patches if needed. ken -- das eine Mal als Tragödie, das andere Mal als Farce -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [libata] Fix HDIO_DRIVE_CMD ioctl sense data check
On Thu, Mar 28, 2013 at 10:56:49PM -0700, Gwendal Grignou wrote: Hmm, not sure. Smartd started and was happy to monitor the disk, but I got two new messages between 'found in smartd database' and 'is SMART capable. Adding to "monitor" list' - Mar 29 17:26:42 ac4tv smartd[2481]: Device: /dev/sda, not capable of SMART Health Status check Mar 29 17:26:42 ac4tv smartd[2481]: Device: /dev/sda, enable SMART Automatic Offline Testing failed. I've seen the first (intermittently) when a drive was starting to fail, and apparently there was a taskfile issue in the days of 2.6.22 which also caused it to appear. I don't think I've seen the second of these before. After going back and forth between the kernel where I reverted your original patch, and regular rc4 plus this new patch the output from running smartctl as root all seems to be consistent (including 'Passed' for the health check). I'm now running with the patch again, and I've started a manual 'long' test (which will take 85 minutes, the default 'offline' is about 150 minutes). > commit 84a9a8cd9d0aa93c17e5815ab8a9cc4c0a765c63 changed the sense key > used for returning task registers, but HDIO_DRIVE_CMD ioctl was > not changed accordingly. > > Tested: check that SMART ENABLE sent using HDIO_DRIVE_CMD returns 0 > instead of EIO. > > Signed-off-by: Gwendal Grignou > --- > drivers/ata/libata-scsi.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c > index 318b413..e05bf4c 100644 > --- a/drivers/ata/libata-scsi.c > +++ b/drivers/ata/libata-scsi.c > @@ -532,8 +532,8 @@ int ata_cmd_ioctl(struct scsi_device *scsidev, void > __user *arg) > struct scsi_sense_hdr sshdr; > scsi_normalize_sense(sensebuf, SCSI_SENSE_BUFFERSIZE, >&sshdr); > - if (sshdr.sense_key == 0 && > - sshdr.asc == 0 && sshdr.ascq == 0) > + if (sshdr.sense_key == RECOVERED_ERROR && > + sshdr.asc == 0 && sshdr.ascq == 0x1D) > cmd_result &= ~SAM_STAT_CHECK_CONDITION; > } > > -- > 1.8.1.3 -- das eine Mal als Tragödie, das andere Mal als Farce -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [libata] Fix HDIO_DRIVE_CMD ioctl sense data check
On Fri, Mar 29, 2013 at 06:31:03PM +, Ken Moffat wrote:
> On Thu, Mar 28, 2013 at 10:56:49PM -0700, Gwendal Grignou wrote:
>
> Hmm, not sure. Smartd started and was happy to monitor the disk,
> but I got two new messages between 'found in smartd database' and
> 'is SMART capable. Adding to "monitor" list' -
>
> Mar 29 17:26:42 ac4tv smartd[2481]: Device: /dev/sda, not capable of
> SMART Health Status check
> Mar 29 17:26:42 ac4tv smartd[2481]: Device: /dev/sda, enable SMART
> Automatic Offline Testing failed.
>
> I've seen the first (intermittently) when a drive was starting to
> fail, and apparently there was a taskfile issue in the days of 2.6.22
> which also caused it to appear. I don't think I've seen the second
> of these before.
>
> After going back and forth between the kernel where I reverted your
> original patch, and regular rc4 plus this new patch the output from
> running smartctl as root all seems to be consistent (including
> 'Passed' for the health check).
>
> I'm now running with the patch again, and I've started a manual
> 'long' test (which will take 85 minutes, the default 'offline' is
> about 150 minutes).
>
Looks like the problem is confined to smartd, smartctl is
different and working fine. The new messages only come from smartd.cpp :
(sorry, long lines to avoid word wrapping)
// capability check: SMART status
if (cfg.smartcheck && ataSmartStatus2(atadev) == -1) {
PrintOut(LOG_INFO,"Device: %s, not capable of SMART Health Status
check\n",name);
cfg.smartcheck = false;
}
and
// enable/disable automatic on-line testing
if (cfg.autoofflinetest) {
// is this an enable or disable request?
const char *what=(cfg.autoofflinetest==1)?"disable":"enable";
if (!smart_val_ok)
PrintOut(LOG_INFO,"Device: %s, could not %s SMART Automatic Offline
Testing.\n",name, what);
else {
// if command appears unsupported, issue a warning...
if (!isSupportAutomaticTimer(&state.smartval))
PrintOut(LOG_INFO,"Device: %s, SMART Automatic Offline Testing
unsupported...\n",name);
// ... but then try anyway
if
((cfg.autoofflinetest==1)?ataDisableAutoOffline(atadev):ataEnableAutoOffline(atadev))
PrintOut(LOG_INFO,"Device: %s, %s SMART Automatic Offline Testing
failed.\n", name, what);
else
PrintOut(LOG_INFO,"Device: %s, %sd SMART Automatic Offline Testing.\n",
name, what);
}
}
I've no idea about the details, but it looks to me as if smartd is
still getting different values returned to it. The capability check
normally was ok (silent), the automatic testing normally showed as
'enabled'd.
ken
--
das eine Mal als Tragödie, das andere Mal als Farce
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [libata] Fix HDIO_DRIVE_CMD ioctl sense data check
On Fri, Mar 29, 2013 at 08:34:43PM +, Ken Moffat wrote: > On Fri, Mar 29, 2013 at 06:31:03PM +0000, Ken Moffat wrote: > I've no idea about the details, but it looks to me as if smartd is > still getting different values returned to it. The capability check > normally was ok (silent), the automatic testing normally showed as > 'enabled'd. > After that I found today's posts in Krzystof Mazur's earlier thread. When I first read that I thought it was for a specific drive, and didn't remember it when I had time to try rc4. The v2 of the patch (with two hunks) fixes it for me too. ken -- das eine Mal als Tragödie, das andere Mal als Farce -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: "ide=reverse" do we still need this?
On Wed, Feb 13, 2008 at 03:32:49PM +, Ken Moffat wrote:
> On Tue, Feb 12, 2008 at 08:43:04PM -0800, Greg KH wrote:
> >
> > Can't you just boot with /dev/disk/by-id/ and an initramfs to not have
> > to worry about such a thing in the future?
> >
Initramfs isn't something I've ever tried, so I'm not about to rush
into it on the server. Maybe I'll try it on a desktop one day.
Anyway, I've now got it running without ide=reverse, details follow
for anybody else who gets a similar problem in the future.
> Can comebody remind me what the initramfs is for in that situation,
> please ? From the little I've noticed, I thought the /dev/disk/by-id
> part went into fstab ? At the moment, I just build the things I
> think I need in to the kernel on that box, without modules.
>
And for the next person asking this, it seems to be so that you
can specify the root= parameter.
> Anyway, I'll try to find time to read my notes to see if I can
> identify what happened/when, and to take the box down again so I
> can try to confirm exactly what the problem is, if it still exists.
> I certainly won't be taking it down until I've written my weekly
> backups to tape at the weekend, so maybe not before next week.
>
Turns out I was wrong about having a SATA disk for the system - I
used to, but then I needed to separate the backups into separate r/o
and r/w filesystems when nfs no longer let me export part of a ro fs
as rw. In the change, my staging area for writing to tape or DVD
moved to the system disk, and the only big-enough disk I could get
locally was parallel ide. So in that setup, ide on a card comes
first.
> > Have you tried the PATA drivers instead of IDE to see if this solves the
> > "moves around" issue? If they work, then you would not need the command
> > line option at all.
>
My first thought was to try using libata for the drives on the
add-on card (sii0680), although it's marked as experimental. Maybe
I picked the wrong driver, but they didn't show up. Reverted to
previous config.
Changed to mount-by-label so that I don't have to change fstab for
the old and new kernels.
Moved the main drive and the CD to libata (sii still old IDE) -
specify sda instead of hda in root=, change system scripts referencing
drives by name (for SMART - system disk is again -d ata, the data raid
moved from hd{e,g} to hd{a,c}), now seems to be working but I expect
I'll notice a few things more in my scripts over the next days.
I also discovered that lilo needed the real node specified in root=
to exist. It complained, so I added a symlink to the hdaX node -
panic'd trying to load rootfs from 0307. Reboot to old kernel, run mknod on
/dev,
repeat, booted.
Ken
--
das eine Mal als Tragödie, das andere Mal als Farce
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2.4.1-ac16: add CDROM_LOCKDOOR ioctl to IDE floppies
Francis, do I understand that you can remove the disk while it is
mounted? If so, there is a later version of ide-floppy.c (0.96) on
sourceforge.net which for some reason hasn't made it into the -ac kernels.
With 2.4.2 vanilla and ide-floppy 0.96 I don't get this problem, it also
removes some i/o error messages I was seeing.
Ken
On Mon, 19 Feb 2001, Francis Galiegue wrote:
> Patch below. It Work For Me(tm) with an IDE ZIP drive.
>
> --- drivers/ide/ide-floppy.c.oldMon Feb 19 13:39:55 2001
> +++ drivers/ide/ide-floppy.cMon Feb 19 13:48:53 2001
> @@ -1517,15 +1517,21 @@
> unsigned int cmd, unsigned long arg)
> {
> idefloppy_pc_t pc;
> + int prevent = (arg) ? 1 : 0;
>
> switch (cmd) {
> case CDROMEJECT:
> + prevent = 0;
> + /* fall through */
> + case CDROM_LOCKDOOR:
> if (drive->usage > 1)
> return -EBUSY;
> - idefloppy_create_prevent_cmd (&pc, 0);
> - (void) idefloppy_queue_pc_tail (drive, &pc);
> - idefloppy_create_start_stop_cmd (&pc, 2);
> + idefloppy_create_prevent_cmd (&pc, prevent);
> (void) idefloppy_queue_pc_tail (drive, &pc);
> + if (cmd == CDROMEJECT) {
> + idefloppy_create_start_stop_cmd (&pc, 2);
> + (void) idefloppy_queue_pc_tail (drive, &pc);
> + }
> return 0;
> case IDEFLOPPY_IOCTL_FORMAT_SUPPORTED:
> return (0);
>
>
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
msdos ignored in 2.4.2, unless modules
Hi, compiled 2.4.2 this afternoon (fresh 2.4.0 tree, patched to 2.4.1 then 2.4.2). I'd selected 'Y' in menuconfig for fat, msdos, and vfat, but when I tried to mount a dos zip disk it told me the kernel didn't support fat. Recompiled with fat, msdos, vfat as modules and it runs fine. I imagine this is a problem in the lists controlling the Makefile, but I didn't understand fs/Makefile. The only thing perhaps unusual in the configuration is using msdos with reiserfs. .config follows Ken # # Automatically generated by make menuconfig: don't edit # CONFIG_X86=y CONFIG_ISA=y # CONFIG_SBUS is not set CONFIG_UID16=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y # # Loadable module support # CONFIG_MODULES=y # CONFIG_MODVERSIONS is not set CONFIG_KMOD=y # # Processor type and features # # CONFIG_M386 is not set # CONFIG_M486 is not set CONFIG_M586=y # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MCRUSOE is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_CMPXCHG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_L1_CACHE_SHIFT=5 CONFIG_X86_USE_STRING_486=y CONFIG_X86_ALIGNMENT_16=y # CONFIG_TOSHIBA is not set # CONFIG_MICROCODE is not set # CONFIG_X86_MSR is not set # CONFIG_X86_CPUID is not set CONFIG_NOHIGHMEM=y # CONFIG_HIGHMEM4G is not set # CONFIG_HIGHMEM64G is not set # CONFIG_MATH_EMULATION is not set # CONFIG_MTRR is not set # CONFIG_SMP is not set # CONFIG_X86_UP_IOAPIC is not set # # General setup # CONFIG_NET=y # CONFIG_VISWS is not set CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_NAMES=y # CONFIG_EISA is not set # CONFIG_MCA is not set # CONFIG_HOTPLUG is not set # CONFIG_PCMCIA is not set CONFIG_SYSVIPC=y # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_SYSCTL=y CONFIG_KCORE_ELF=y # CONFIG_KCORE_AOUT is not set CONFIG_BINFMT_AOUT=m CONFIG_BINFMT_ELF=y CONFIG_BINFMT_MISC=m CONFIG_PM=y # CONFIG_ACPI is not set # CONFIG_APM is not set # # Memory Technology Devices (MTD) # # CONFIG_MTD is not set # # Parallel port support # CONFIG_PARPORT=y CONFIG_PARPORT_PC=y # CONFIG_PARPORT_PC_FIFO is not set # CONFIG_PARPORT_PC_SUPERIO is not set # CONFIG_PARPORT_AMIGA is not set # CONFIG_PARPORT_MFC3 is not set # CONFIG_PARPORT_ATARI is not set # CONFIG_PARPORT_SUNBPP is not set # CONFIG_PARPORT_OTHER is not set # CONFIG_PARPORT_1284 is not set # # Plug and Play configuration # CONFIG_PNP=y CONFIG_ISAPNP=y # # Block devices # CONFIG_BLK_DEV_FD=y # CONFIG_BLK_DEV_XD is not set # CONFIG_PARIDE is not set # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_BLK_DEV_DAC960 is not set # CONFIG_BLK_DEV_LOOP is not set # CONFIG_BLK_DEV_NBD is not set # CONFIG_BLK_DEV_RAM is not set # CONFIG_BLK_DEV_INITRD is not set # # Multi-device support (RAID and LVM) # # CONFIG_MD is not set # CONFIG_BLK_DEV_MD is not set # CONFIG_MD_LINEAR is not set # CONFIG_MD_RAID0 is not set # CONFIG_MD_RAID1 is not set # CONFIG_MD_RAID5 is not set # CONFIG_BLK_DEV_LVM is not set # # Networking options # CONFIG_PACKET=y # CONFIG_PACKET_MMAP is not set # CONFIG_NETLINK is not set # CONFIG_NETFILTER is not set # CONFIG_FILTER is not set CONFIG_UNIX=y CONFIG_INET=y CONFIG_IP_MULTICAST=y # CONFIG_IP_ADVANCED_ROUTER is not set # CONFIG_IP_PNP is not set # CONFIG_NET_IPIP is not set # CONFIG_NET_IPGRE is not set # CONFIG_IP_MROUTE is not set # CONFIG_INET_ECN is not set # CONFIG_SYN_COOKIES is not set # CONFIG_IPV6 is not set # CONFIG_KHTTPD is not set # CONFIG_ATM is not set # CONFIG_IPX is not set # CONFIG_ATALK is not set # CONFIG_DECNET is not set # CONFIG_BRIDGE is not set # CONFIG_X25 is not set # CONFIG_LAPB is not set # CONFIG_LLC is not set # CONFIG_NET_DIVERT is not set # CONFIG_ECONET is not set # CONFIG_WAN_ROUTER is not set # CONFIG_NET_FASTROUTE is not set # CONFIG_NET_HW_FLOWCONTROL is not set # # QoS and/or fair queueing # # CONFIG_NET_SCHED is not set # # Telephony Support # # CONFIG_PHONE is not set # CONFIG_PHONE_IXJ is not set # # ATA/IDE/MFM/RLL support # CONFIG_IDE=y # # IDE, ATA and ATAPI Block devices # CONFIG_BLK_DEV_IDE=y # CONFIG_BLK_DEV_HD_IDE is not set # CONFIG_BLK_DEV_HD is not set CONFIG_BLK_DEV_IDEDISK=y # CONFIG_IDEDISK_MULTI_MODE is not set # CONFIG_BLK_DEV_IDEDISK_VENDOR is not set # CONFIG_BLK_DEV_IDEDISK_FUJITSU is not set # CONFIG_BLK_DEV_IDEDISK_IBM is not set # CONFIG_BLK_DEV_IDEDISK_MAXTOR is not set # CONFIG_BLK_DEV_IDEDISK_QUANTUM is not set # CONFIG_BLK_DEV_IDEDISK_SEAGATE is not set # CONFIG_BLK_DEV_IDEDISK_WD is not set # CONFIG_BLK_DEV_COMMERIAL is not set # CONFIG_BLK_DEV_TIVO is not set # CONFIG_BLK_DEV_IDECS is not set CONFIG_BLK_DEV_IDECD=y # CONFIG_BLK_DEV_IDETAPE is not set CONFIG_BLK_DEV_IDEFL
Re: reiserfs: still problems with tail conversion
(reisertest)
I get the same problems with straight 2.4.2, machine is a k5 with
32Mb. The test results vary depending on what else is on the partition,
but in each case the last file affected is 01017 and there are sequences
of previous_number+4, for up to 8 files (but next file after this might be
previous+7 or previous +15, or sporadic). From other problems I've seen on
the list, maybe I need more memory to run reiserfs ?
This happens whether I compile the kernel (and/or the test program) with
Red Hat's revised gcc-2.96 or with egcs. First testing was with a
partition created from the rpm version of mkreiserfs, while running a
2.96-built-kernel. I've now recreated the partition while running a kernel
compiled with egcs ('kgcc'), the only difference is some of the numbers
for the affected files differ.
Partition approx 1.7Gb, built with defaults, block size is 4096.
More details of config or whatever available if required.
Ken
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: reiserfs: still problems with tail conversion
Chris,
it works nicely here (i586, 32Mb, Red Hat's gcc-2.96-69). Thanks.
Ken
On Sun, 25 Feb 2001, Chris Mason wrote:
>
> Hi guys,
>
> This patch should take care of the other cause for null bytes
> in small files. It has been through a few hours of testing,
> with some of the usual load programs + Erik's code concurrently.
>
> I'll let things run overnight to try and find more bugs. The
> patch is against 2.4.2, and does a few things:
>
> don't dirty the direct->indirect target until all direct items
> have been copied in. Before it was dirtied for each direct item.
>
> make the target up to date before dirtying (it was done after).
>
> don't try to zero the unused part of the target until all bytes
> have been copied. This was the big bug, it was zeroing previously
> copied bytes.
>
> Any testing on non-production machines would be appreciated,
> I'll forward to Linus/Alan once I've gotten more feedback.
>
> -chris
>
> diff -ur diff/linux/fs/reiserfs/inode.c linux/fs/reiserfs/inode.c
> --- diff/linux/fs/reiserfs/inode.cTue Jan 16 14:14:22 2001
> +++ linux/fs/reiserfs/inode.c Sun Feb 25 16:25:31 2001
> @@ -771,6 +771,7 @@
> ** flush unbh before the transaction commits
> */
> reiserfs_add_page_to_flush_list(&th, inode, unbh) ;
> + mark_buffer_dirty(unbh) ;
>
> //inode->i_blocks += inode->i_sb->s_blocksize / 512;
> //mark_tail_converted (inode);
> diff -ur diff/linux/fs/reiserfs/stree.c linux/fs/reiserfs/stree.c
> --- diff/linux/fs/reiserfs/stree.cMon Jan 15 18:31:19 2001
> +++ linux/fs/reiserfs/stree.c Sun Feb 25 16:25:31 2001
> @@ -1438,7 +1438,6 @@
>
> if ( p_s_un_bh ) {
> int off;
> -int block_off ;
> char *data ;
>
> /* We are in direct2indirect conversion, so move tail contents
> @@ -1452,7 +1451,8 @@
> ** the unformatted node, which might schedule, meaning we'd have to
> ** loop all the way back up to the start of the while loop.
> **
> - ** The unformatted node is prepared and logged after the do_balance.
> + ** The unformatted node must be dirtied later on. We can't be
> + ** sure here if the entire tail has been deleted yet.
> **
> ** p_s_un_bh is from the page cache (all unformatted nodes are
> ** from the page cache) and might be a highmem page. So, we
> @@ -1463,24 +1463,12 @@
>
> data = page_address(p_s_un_bh->b_page) ;
> off = ((le_ih_k_offset (&s_ih) - 1) & (PAGE_CACHE_SIZE - 1));
> -block_off = off & (p_s_un_bh->b_size - 1) ;
> memcpy(data + off,
> B_I_PITEM(PATH_PLAST_BUFFER(p_s_path), &s_ih), n_ret_value);
> -
> - /* clear out the rest of the block past the end of the file. */
> - if (block_off + n_ret_value < p_s_un_bh->b_size) {
> - memset(data + off + n_ret_value, 0,
> -p_s_un_bh->b_size - block_off - n_ret_value) ;
> - }
> }
>
> /* Perform balancing after all resources have been collected at once. */
> do_balance(&s_del_balance, NULL, NULL, M_DELETE);
> -
> -/* see comment above for why this is after the do_balance */
> -if (p_s_un_bh) {
> -mark_buffer_dirty(p_s_un_bh) ;
> -}
>
> /* Return deleted body length */
> return n_ret_value;
> diff -ur diff/linux/fs/reiserfs/tail_conversion.c linux/fs/reiserfs/tail_conversion.c
> --- diff/linux/fs/reiserfs/tail_conversion.c Mon Feb 19 13:07:32 2001
> +++ linux/fs/reiserfs/tail_conversion.c Sun Feb 25 19:42:54 2001
> @@ -32,6 +32,7 @@
> struct super_block * sb = inode->i_sb;
> struct buffer_head *up_to_date_bh ;
> struct item_head * p_le_ih = PATH_PITEM_HEAD (path);
> +unsigned long total_tail = 0 ;
> struct cpu_key end_key; /* Key to search for the last byte of the
> converted item. */
> struct item_head ind_ih; /* new indirect item to be inserted or
> @@ -121,10 +122,19 @@
> n_retval = reiserfs_delete_item (th, path, &end_key, inode,
>up_to_date_bh) ;
>
> + total_tail += n_retval ;
> if (tail_size == n_retval)
> // done: file does not have direct items anymore
> break;
>
> +}
> +/* if we've copied bytes from disk into the page, we need to zero
> +** out the unused part of the block (it was not up to date before)
> +** the page is still kmapped (by whoever called reiserfs_get_block)
> +*/
> +if (up_to_date_bh) {
> +unsigned pgoff = (tail_offset + total_tail - 1) & (PAGE_CACHE_SIZE - 1);
> + memset(page_address(unbh->b_page) + pgoff, 0, n_blk_size - total_tail) ;
> }
>
> inode->u.reiserfs_i.i_first_direct_byte = U32_MAX;
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please
Every Make option ends in error.
Hi guys, I guess I'm doing something stupid, so please can somebody point it out and put me out of my misery ? Copied a plain 2.4.0 tree to a new directory, patched it to 2.4.1 without any errors. Then I realised it had all the object files from my last compile, so I thought "make mrproper" was called for. It did a little, then rm: include/asm: is a directory make: *** [mrproper] Error 1 "make clean" and "make oldconfig" stop with similar errors, "make clean" is in "symlinks" at the time. This piece of makefile looks to be the same as in 2.4.0, which worked. I'm running make 3.77. Any comments, please ? Ken - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Every Make option ends in error.
On Fri, 2 Feb 2001, Mark Hahn wrote: > > I guess I'm doing something stupid, so please can somebody point it out > > and put me out of my misery ? > > don't use cp to copy kernel trees unless you use -s. > Thanks for the advice, Mark. I'll give it a go in a minute (got to log off this box and connect the monitor to the test box). I figured that since I've got a 1.5Gb partition for kernels, putting a third one in there wouldn't cause any grief. Ken - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Every Make option ends in error.
Dick, and Mark, thanks. It's compiling nicely now. We learn by experience. Cheers, Ken > Not to worry. In your new Linux directory tree do: > > cd include > mv asm /tmp # or /usr/src, someplace temporary. > > cd .. # Back to Linux > cp .config .. # Save your configuration > make mrproper # Make like a distribution > cp ../.config . # Restore configuration > make oldconfig# Re-do configuration > make dep # Re-do dependencies > make bzImage # Doit toit > > After everything works, recursively delete the saved 'asm' > directory that was moved outside the kernel tree. > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[OT] gcc-3 problem (oops in df)
I see people on this list are using gcc-3 snapshots, so I thought I'd ask advice here to narrow the problem down, before posting a gcc bug report. I've been sitting on this for a couple of days without getting anywhere. If I use a recent gcc snapshot (example : 4th June), I get an oops if I try to use "df". The following output from ksymoops relates to a recent example. No modules were loaded at the time, so the modules file was empty. Can people on this list using x86 gcc-3 snapshots let me know if "df" works for them, and if so a summary of their hardware / .config . "df" only gets as far as printing the column titles before the oops occurs. As far as I can tell, the only things at all out of the ordinary are that I have an AMD K6-2/500 and one of my partitions uses reiserfs (which was why I tried -ac6). The oops follows, I wasn't using any modules at the time. ksymoops 2.4.1 on i586 2.4.5-ac6. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.5-ac6/ (default) -m /boot/System.map-2.4.5-ac6 (specified) No modules in ksyms, skipping objects Warning (read_lsmod): no symbols in lsmod, is /proc/modules a valid lsmod file? Jun 6 11:42:27 reg_kipling kernel: Unable to handle kernel paging request at virtual address a2fcc113 Jun 6 11:42:27 reg_kipling kernel: c11ec8fd Jun 6 11:42:27 reg_kipling kernel: *pde = Jun 6 11:42:27 reg_kipling kernel: Oops: 0002 Jun 6 11:42:27 reg_kipling kernel: CPU:0 Jun 6 11:42:27 reg_kipling kernel: EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 Jun 6 11:42:27 reg_kipling kernel: EFLAGS: 00010286 Jun 6 11:42:27 reg_kipling kernel: eax: c2cd1f90 ebx: ecx: edx: c11ec8fc Jun 6 11:42:27 reg_kipling kernel: esi: edi: ebp: c113a2fc esp: c2cd1f98 Jun 6 11:42:27 reg_kipling kernel: ds: 0018 es: 0018 ss: 0018 Jun 6 11:42:27 reg_kipling kernel: Process df (pid: 521, stackpage=c2cd1000) Jun 6 11:42:27 reg_kipling kernel: Stack: ffe7 b150 c11c9e94 0009 0001 0004 c2cd 08051ea0 Jun 6 11:42:27 reg_kipling kernel:b8e0 b848 c0107277 08051ea0 b7f0 401420e0 08051ea0 b8e0 Jun 6 11:42:27 reg_kipling kernel:b848 0063 002b 002b 0063 400efd61 0023 0246 Jun 6 11:42:27 reg_kipling kernel: Call Trace: [system_call+55/64] Jun 6 11:42:27 reg_kipling kernel: Code: a2 13 c1 fc a2 13 c1 fc c8 1e c1 6c 8c 16 c1 6c 8c 16 c1 10 >>EIP; c11ec8fd<= Code; c11ec8fd <_EIP>: Code; c11ec8fd<= 0: a2 13 c1 fc a2mov%al,0xa2fcc113 <= Code; c11ec902 5: 13 c1 adc%ecx,%eax Code; c11ec904 7: fccld Code; c11ec905 8: c8 1e c1 6c enter $0xc11e,$0x6c Code; c11ec909 c: 8c 16 movl %ss,(%esi) Code; c11ec90b e: c1 6c 8c 16 c1shrl $0xc1,0x16(%esp,%ecx,4) Code; c11ec910 13: 10 00 adc%al,(%eax) 1 warning issued. Results may not be reliable. For what it's worth, I also get the "probable hardware bug. clock timer" message from this kernel with the gcc-3 snapshot. The mobo is a Jetway 542C, with an ALi chipset. Needless to say, everything works fine with gcc-2.96. .config and dmesg output attached. Cheers. Ken -- That's it, six times nine, forty-two. Home page : http://www.kenmoffat.uklinux.net # # Automatically generated make config: don't edit # CONFIG_X86=y CONFIG_ISA=y # CONFIG_SBUS is not set CONFIG_UID16=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y # # Loadable module support # CONFIG_MODULES=y # CONFIG_MODVERSIONS is not set CONFIG_KMOD=y # # Processor type and features # # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUM4 is not set CONFIG_MK6=y # CONFIG_MK7 is not set # CONFIG_MCRUSOE is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MCYRIXIII is not set CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y # CONFIG_RWSEM_GENERIC_SPINLOCK is not set CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_X86_L1_CACHE_SHIFT=5 CONFIG_X86_ALIGNMENT_16=y CONFIG_X86_TSC=y CONFIG_X86_USE_PPRO_CHECKSUM=y # CONFIG_TOSHIBA is not set # CONFIG_MICROCODE is not set # CONFIG_X86_MSR is not set # CONFIG_X86_CPUID is not set CONFIG_NOHIGHMEM=y # CONFIG_HIGHMEM4G is not set # CONFIG_HIGHMEM64G is not set # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y # CONFIG_SMP is not set # CONFIG_X86_UP_APIC is not set # CONFIG_X86_UP_IOAPIC is not set # # General setup # CONFIG_NET=y # CONFIG_VISWS is not s
ondemand cpufreq ineffective in 2.6.12 ?
Hi, I've been using the ondemand governor on athlon64 winchesters for a few weeks. I've just noticed that in 2.6.12 the frequency is not increasing under load, it remains at the lowest frequency. This seems to be down to something in 2.6.12-rc6, but I've seen at least one report since then that ondemand works fine. Anybody else seeing this problem ? Testcase: boot (my bootscripts set the governor to ondemand), set the governor to ondemand, performance, powersave and untar a nice big bzip2'd tarball (gcc-3.4.1) from an nfs mount. All using the config from 2.6.11.9 and defaults for new options. kernel 2.6.11.92.6.12-rc5 2.6.12-rc6 2.6.12 ondemand20.8 sec21.3 sec33.9 sec34.1 sec performance 21.3 sec22.0 sec22.6 sec20.1 sec powersave 32.4 sec33.1 sec33.6 sec33.9 sec I don't have confidence that the numbers are more repeatable than +/- 2 seconds on this, they just illustrate that ondemand used to give a similar time to performance, but now doesn't. Other intermediate and later tests have been omitted for clarity, but 2.6.12.2 does show the same problem. Since 2.6.12-rc6, 'ondemand' appears to be still accepted (the echo to scaling_governor returns 0, and the displayed frequency drops back if I try going from performance to ondemand). When ondemand appears to work properly, /proc/cpuinfo shows the speed jumping to 2 GHz, then falling back to 1.8 after the untar ends, then back to 1.0 GHz. In the problem cases, the speed remains at 1GHz. As far as I can see, nothing untoward shows in the logs. Any suggestions, please ? Ken -- das eine Mal als Tragödie, das andere Mal als Farce - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ondemand cpufreq ineffective in 2.6.12 ?
On Mon, 11 Jul 2005, Ken Moffat wrote: > Hi, > > I've been using the ondemand governor on athlon64 winchesters for a few > weeks. I've just noticed that in 2.6.12 the frequency is not > increasing under load, it remains at the lowest frequency. This seems > to be down to something in 2.6.12-rc6, but I've seen at least one report > since then that ondemand works fine. Anybody else seeing this problem ? > And just for the record, it's still not working in 2.6.13-rc2. Oh well, back to 2.6.11 for this box. -- das eine Mal als Tragödie, das andere Mal als Farce - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ondemand cpufreq ineffective in 2.6.12 ?
On Tue, 12 Jul 2005, Eric Piel wrote: > It's a tradeoff :-) > > Ken, does this solve your problems (but that seems strange that all your > tasks are nice'd) ? > > Eric > I was going to say that niceness didn't affect what I was doing, but I've just rerun it [ in 2.6.11.9 ] and I see that tar and bzip2 show up with a niceness of 10. I'm starting to feel a bit out of my depth here ... Ken -- das eine Mal als Tragödie, das andere Mal als Farce - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ondemand cpufreq ineffective in 2.6.12 ?
On Tue, 12 Jul 2005, Ken Moffat wrote: > I was going to say that niceness didn't affect what I was doing, but > I've just rerun it [ in 2.6.11.9 ] and I see that tar and bzip2 show up > with a niceness of 10. I'm starting to feel a bit out of my depth here OK, Con was right, and I didn't initially make the connection. In 2.6.11, untarring a .tar.bz2 causes tar and bzip2 to run with a niceness of 10, but everything is fine. In 2.6.12, ondemand _only_ has an effect for me in this example if I put on my admin hat and renice the bzip2 process (tried 0, that works) - renicing the tar process has no effect (obviously, that part doesn't push the processor). So, from a user's point of view it's broken. Ken -- das eine Mal als Tragödie, das andere Mal als Farce - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ondemand cpufreq ineffective in 2.6.12 ?
On Tue, 12 Jul 2005, Daniel J Blueman wrote: > I find the ondemand governor works as expected with 2.6.12 on my > Athlon64 Winchester [1]; as soon as I bzip2 a file, processor freq is > pinned at 1.8GHz and drops to 1GHz when idle. > Thanks, it seems to be a niceness problem - if I run from an xterm as a user, the processes get a niceness of 10. If the bzip2 process gets reniced to 0, all is sweetness. So, either I have to not use X, or stick with 2.6.11. Ken -- das eine Mal als Tragödie, das andere Mal als Farce - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ondemand cpufreq ineffective in 2.6.12 ?
On Tue, 12 Jul 2005, Eric Piel wrote: > > Just by couriosity, I wonder how your processes are automatically > reniced to 10 ? > In my case, running from an xterm. Ken -- das eine Mal als Trag�die, das andere Mal als Farce - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Kconfig: lxdialog: Enable UTF8
On Wed, 13 Jul 2005, Jan Engelhardt wrote: > Hi, > > > utf-8 enabled vc consoles (/dev/tty1) usually show line drawing > graphics with the ascii set, e.g. + - and | for lxdialog (and many other apps > btw) > > The following patch brings back the real graphics for lxdialog, which are > normally present in these cases: > - non-utf8 vc > - xterm (u8 / non-u8) > OK, I'll bite - non utf8 here, and no libncursesw : a quick google suggests I can get it if I recompile ncurses with --enable-widec, but why would I want to do that ? Ken -- das eine Mal als Tragödie, das andere Mal als Farce - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Kconfig: lxdialog: Enable UTF8
On Sat, 16 Jul 2005, Sam Ravnborg wrote: > > > > OK, I'll bite - non utf8 here, and no libncursesw : a quick google > > suggests I can get it if I recompile ncurses with --enable-widec, but > > why would I want to do that ? > Could you try if specifying both libraries works for you. the 'w' > version first. Then we can use the 'w' version when available but > fall-back to the normal case if not. > > Sam > Didn't work, I get the not unexpected "cannot find -lncursesw". I think some sort of pre-test will be needed to see which one exists. I'm weak on doing this in a Makefile, but I'll have a look tonight or tomorrow. Ken -- das eine Mal als Tragödie, das andere Mal als Farce - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Kconfig: lxdialog: Enable UTF8
On Sat, 16 Jul 2005, Ken Moffat wrote: > On Sat, 16 Jul 2005, Sam Ravnborg wrote: > > > > > > > OK, I'll bite - non utf8 here, and no libncursesw : a quick google > > > suggests I can get it if I recompile ncurses with --enable-widec, but > > > why would I want to do that ? > > Could you try if specifying both libraries works for you. the 'w' > > version first. Then we can use the 'w' version when available but > > fall-back to the normal case if not. > > > > Sam > > > > Didn't work, I get the not unexpected "cannot find -lncursesw". I > think some sort of pre-test will be needed to see which one exists. > I'm weak on doing this in a Makefile, but I'll have a look tonight or > tomorrow. > Hmm, I can repeatedly test by linking against candidate libraries by converting the current if...else test to nested if..else (adding -lcurses while I'm at it), but I can't crack setting HOST_LOADLIBES from that - if the link succeeded, I'm into the shell code to tidy up and from there I can't set a variable in the Makefile . I don't want to attempt to build a configure script in a Makefile - even if it's possible, I think it would be nasty. So unless I've misunderstood your question, no, I can't specify both libraries. Note that I originally asked why on a system that doesn't use utf8, I should rebuild ncurses. A sufficiently compelling reason would make me rebuild. Ken -- das eine Mal als Tragödie, das andere Mal als Farce - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Compiling module-init-tools versions after v3.0
On Mon, 8 Aug 2005, Andrew Haninger wrote: > > The problem is that compiling module-init-tools versions after 3.0 > seem require docbook-utils (the compile fails on a docbook2man > operation) to be installed and docbook-utils requires jade which will > not compile. I found one jade package called jade-1.2.1 (from '98 or > '99) which will not compile. I tried openjade, but it does not seem to > work when compiling docbook-tools (I made a symlink from the openjade > binary to "jade"). > per LFS (http://www.linuxfromscratch.org/lfs/) make DOCBOOKTOMAN="" (or look at BLFS for the gory details of docbook) Ken -- das eine Mal als Tragödie, das andere Mal als Farce - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Partitioning problems on x86_64 (fwd)
Apologies if these are known problems, but I don't recall seeing them mentioned recently. I'm running an athlon64 with 2.6.12.3, in the middle of rebuilding it to run 64-bit. The main drive used to be in an i686 machine for testing, and it got to a point where I wanted to repartition. Under a 64-bit kernel, every time I tried to rewrite the partition table in fdisk I got an error 16, device or resource busy, with a message that the new partition table would be used at the next boot. (Yes, I had umounted everything except '/' on hda5. ) Since making a filesystem on my new /dev/hda7 and mounting it showed the size of the old hda7 in 'df', I tried rebooting but the failure to rewrite the partition table continued. At one point, I thought I'd try the stronger magic of sfdisk, but that just reported some error in the number of bytes read, and decided it couldn't read the partition table. In the end I was able to repartition successfully by rebooting to a 2.6.12.1 i686 kernel. This box is destined to become my new home server, so running test kernels on it isn't something I'm keen to try, but I thought I'd better report this, and the successful workaround of using an i686 kernel, which will be a bit of a pain on pure64. Ken -- das eine Mal als Tragödie, das andere Mal als Farce - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Partitioning problems on x86_64 (fwd)
On Thu, 11 Aug 2005, Lennart Sorensen wrote: > > The kernel won't reread the partition table as long as ANY part of that > disk is mounted. Reboot (which of course unmounts everything) to reread > the partition table. > OK, I've noted that now, thanks for the clue. > > Just any reboot should have worked. Once you reboot it reads the > updated partition table and THEN you can mkfs the new partitions. Until > /proc/partitions matches what you see in fdisk, you really don't want to > try access the partitions since it won't match on the next boot anyhow. > > Len Sorensen > It certainly _seemed_ that the kernel was telling me one thing and fdisk -l another, even after a reboot. But because I hadn't appreciated the importance of rebooting before accessing the new partitions, I probably threw in some extra 'mkfs' commands to spice up the mix. Ken -- das eine Mal als Tragödie, das andere Mal als Farce - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: init wont start on VIA EPIA 5000 500mhz board and randomely wont start on VIA EPIA MII 10000
On Sat, Jan 05, 2008 at 05:14:08PM -0800, mathewss wrote:
> I have been trying to figure this out a while now with printk's all over my
> kernel as well as adding kdb and tracing the int3 events.
>
> I have tried various 2.6 kernels and so far all i have tried do this.
>
> My current tests are on 2.6.22.10
>
> I have a simple init binary I compiled static that is my init that is loaded
> into an init file system. I am not using cpio but that did not seem to matter.
> begin testinit.c
> #include
> #include
> int main(int argc, char *argv[])
> {
>printf("Hello world!\n");
>sleep(9);
> }
> end
>
> I am using syslunux to start my kernel and appending the follwiing startup
> command most of this is specific to my true init script but again im using a
> "hello world" script to debug this for now.
>
> append debug kidb=early console=ttyS0,384008n initrd=ufoinit.img
> init=/testinit rw var_size=12M tmp_size=MAX log_size=16M root_size=64M
> root=/dev/ram0 boot=/dev/hda1,msdos rw pkgpath=/dev/hda1:msdos rw verbose
> DELAY=0 TEST=0 DEBUG=0 VERBOSE=0 UFO=root,etc,modules
>
> On an intel CA810EEA 800mhz board or QEMU this runs fine but on the via
> boards it dies right after "Freeing unused kernel memory: 132k freed"
>
That will be where it invokes the init program, I think, so the
kernel is probably not to blame.
> on the 500mhz board it dies every time on the 800mhz it is random.
>
For the 500MHz, this sounds like the "i686 implies cmov" problem -
gcc thinks that all i686 CPUs understand a particular instruction
('cmov', if my brain cells haven't totally given up), but early via
processors didn't. Haven't seen too many references to this
recently, so perhaps recent versions of gcc have fixed this, or
perhaps people know of a workaround.
I suggest that your userspace (glibc and gcc, I suppose) is built
for i686 and uses the instruction that your CPU doesn't understand.
The 800MHz might be different, I thought those did provide the
instruction. Have you checked the memory with memtest86 ? For the
cases where it doesn't die, perhaps you should give it an init which
is going to do something, and see if it actually manages to boot any
of the time. If so, that would confirm that the two CPUs are not
identical in their capabilities. It wouldn't explain the less than
100% success, of course, so the usual suspects (crap hardware,
failing memory, dodgy power supplies) would need to be investigated.
As always, this is intended to be helpful, but treat it with a
grain of salt, I could well be talking out of a different orifice
than my mouth. My last experience with a via processor was a 1.2GHz
beastie which certainly understood all i686 instructions, but
managed to make snails look fast, and wasn't as power-frugal as
expected, so I might be prejudiced.
> I have noticed that i get the elf binarly loading into user space with some
> page_faults then I get blasted with do_notify_resume with 0x04 or
> TIF_SIGPENDING over and over as if its in an infinite loop.
>
> This begins shortly after load_elf_binary -> clear_user i think right after
> a page_fault during the clear_user. I dont even know why that signal is being
> sent on other hardware it never happens.
>
> I am not even sure what do try next.
>
Find a toolchain built for i586 ? (Or preferably i486, I think I
remember comments that early via CPUs run better when optimised for
i486).
If you think your own toolchain is compiled for i586, you could try
downloading one of the distros which definitely is built for i586 or
i486 - if that works, it's a userspace compile problem. Or, perhaps,
the kernel actually needs to be built for i486 - I doubt that, but I
don't have the hardware.
Ken
--
das eine Mal als Tragödie, das andere Mal als Farce
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: syntax highlighting, emacs ([PATCH 0/2] Colored kernel output (run2))
On Mon, Oct 08, 2007 at 12:11:21AM +0200, Jan Engelhardt wrote: > > Actually, blue is perceived as one of the darkest colors by the human > eye. There is a reason that the RGB -> grayscale transformation uses > the following weighting: r=76 g=154 b=26. But, not every video card reproduces blue in the same way, let alone every monitor - somewhere I've got an old CRT monitor where blue text was mostly unreadable (_too_dark_). For photo-editing, I now use xgamma to get adequately-consistent results on whichever of 4 machines I'm using (one LCD monitor, with KVM switch) - the settings for the individual machines are very different. And, of course, people have different colour vision (and unless we are labelled as colour-blind, we each regard our colour vision as "normal"). So, what is perfectly acceptable for you on specific hardware may be totally unusable for someone else. Ken -- das eine Mal als Tragödie, das andere Mal als Farce - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: patches to 2.6.9 and 2.6.10 - make menuconfig shows "v2.6.8.1"
On Thu, 27 Jan 2005, Viktor Horvath wrote: > Hello everybody, > > today I patched myself up from 2.6.7 vanilla to 2.6.10 vanilla, but > after all patches succeeded, "make menuconfig" shows "v2.6.8.1 > Configuration". Even worse, a compiled kernel calls in his bootlog > himself "2.6.8.1". When installing the whole kernel package, this > behaviour doesn't show up. > Looks like you went 2.6.7, 2.6.8, 2.6.8.1 - you didn't *need* 2.6.8.1, 2.6.9 is against 2.6.8 not 2.6.8.1. So, when you applied 2.6.9 you got rejections (at a minimum, the top level Makefile, but the other stuff from 2.6.8.1 should have rejected because it had already been applied). >From there onwards, the top level Makefile still contains the 2.6.8.1 version info and doesn't match what the next patch is looking to change. Whenever you apply patches, you need to make sure there are no errors! e.g. use 'find' to look for '*.rej' files. Ken -- das eine Mal als Tragödie, das andere Mal als Farce - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] what should 'uptime' be on suspend?
On Thu, Jul 19, 2007 at 10:42:22PM -0400, Bill Davidsen wrote: > I just found a machine which will resume after suspend to memory, using > the mainline kernel (no suspend2 patch). > > On resume I was looking at the uptime output, and it was about six > minutes, FAR longer than the time since resume. So the topic for > discussion is, should the uptime be > - time sine the original boot > - total uptime since first boot, not counting the time suspended > - time since resume > - some other time around six minutes > > Any of the first three could be useful and "right" for some casesm thus > discussion invited. > My ibook has always been able to suspend to RAM. For a long while, uptime was shown as the time since the last boot. At some point, maybe about a year ago, this was "corrected" to show time since boot _less_ time suspended. To be clear, the ibook suspends when I close the lid and resumes when I open it. Uptime used to be convenient, because I could work out when I'd last booted. Ken -- das eine Mal als Tragödie, das andere Mal als Farce - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] what should 'uptime' be on suspend?
On Fri, Jul 20, 2007 at 10:42:15AM -0700, Randy Dunlap wrote: > > man uptime: > uptime - tell how long the system has been running > > I claim that the system is not running when it is suspended, > so the suspension time should not be included in uptime. > So, maybe I shouldn't have put corrected in inverted commas, because this was a real correction and my previous usage was an unintended side-effect of an error. Anyway, the current behaviour is known and I guess any attempt to change it (e.g. to what Bill was expecting) won't be well received. Ken -- das eine Mal als Tragödie, das andere Mal als Farce - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] what should 'uptime' be on suspend?
On Sat, Jul 21, 2007 at 09:54:37AM -0400, Bill Davidsen wrote: > > So is setting it to a random number considered correct behavior? Any of > the first three values I mentioned would make sense, but the value I see > is neither time since resume, time since power-on to do the resume, or > any of the logical uptime values. That was the whole point of the > original post, the uptime reported makes no sense at all. > I assumed you had booted for a short time, suspended, resumed, and then noticed the uptime was longer than time since resume. If you think there is a bug it might help to do a cold boot, at some point note uptime and then immediately suspend, resume some time later, immediately note uptime (including local time), keep it running, and later monitor uptime against local time (i.e. the local time will let you know the change you expect to see in uptime). You might also want to confirm that the local time is maintained correctly. Ken -- das eine Mal als Tragödie, das andere Mal als Farce - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: x86 instability with 2.6.1{8,9}
On Sun, Jan 07, 2007 at 02:26:41PM +, Ken Moffat wrote: > > I guess that when it does have problems, it is mostly within 30 > minutes of booting - otherwise, it can be up all day. So, for the > moment I'm hopeful that changing the config will help, but it will > be several days before I feel at all confident. > Update: it doesn't seem to relate to using/not using APIC. Last Thursday it twice failed during booting (from cold), with messages all over the screen. Again, nothing reached the logs despite my best attempts. The second time, I scrolled back to try to copy it by hand, but there were several sets of messages and I'm not sure if I'd managed to get to the first of them, or if that had dropped out. It seemed to be something to do with highmem (also noticed highmem in the screen messages the first time). I tried to copy it by hand, but it all scrolled out before I'd copied anything useful as a load of 'atkbd.c Spurious ACK on isa0060/serio' messages appeared. Today, I've built 2.6.19.2 without highmem (the box only has 1GB, dunno why I'd included that in the original config) and I will continue to wait patiently for either a week without problems, or something that I can manage to note - although I think at the moment that the second coming of the great prophet Zarquon is more likely. Ken -- das eine Mal als Tragödie, das andere Mal als Farce - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Weird harddisk behaviour
On Tue, Jan 16, 2007 at 02:27:06PM +0100, Turbo Fredriksson wrote: > A couple of weeks ago my 400Gb SATA disk crashed. I just > got the replacement, but I can't seem to be able to create > a filesystem on it! > > This is a PPC (Pegasos), running 2.6.15-27-powerpc (Ubuntu Dapper > v2.6.15-27.50). Hi Turbo, I think you have mac partitions (the first item is the partition map itself - very different from the dos partitions common on x86). Certainly, fdisk from util-linux doesn't know about mac disks, and I thought the same was true for cfdisk and sfdisk. Many years ago there was mac-fdisk, I think also known as pdisk, but nowadays the common tool for partitioning mac disks is probably parted. > [EMAIL PROTECTED]:~# mke2fs -v -j /dev/sdb1 > mke2fs 1.38 (30-Jun-2005) > Filesystem label= > OS type: Linux > Block size=4096 (log=2) > Fragment size=4096 (log=2) > 48840704 inodes, 97677200 blocks > 4883860 blocks (5.00%) reserved for the super user > First data block=0 > 2981 block groups > 32768 blocks per group, 32768 fragments per group > 16384 inodes per group > Superblock backups stored on blocks: > 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, > 2654208, > 4096000, 7962624, 11239424, 2048, 23887872, 71663616, 78675968 > > Writing inode tables: done > Creating journal (32768 blocks): done > Writing superblocks and filesystem accounting information: done > > This filesystem will be automatically checked every 36 mounts or > 180 days, whichever comes first. Use tune2fs -c or -i to override. > [EMAIL PROTECTED]:~# e2fsck /dev/sdb1 > e2fsck 1.38 (30-Jun-2005) > e2fsck: Filesystem revision too high while trying to open /dev/sdb1 > The filesystem revision is apparently too high for this version of e2fsck. > (Or the filesystem superblock is corrupt) > > > The superblock could not be read or does not describe a correct ext2 > filesystem. If the device is valid and it really contains an ext2 > filesystem (and not swap or ufs or something else), then the superblock > is corrupt, and you might try running e2fsck with an alternate superblock: > e2fsck -b 8193 > > [EMAIL PROTECTED]:~# dmesg | tail -n1 > [154695.371073] EXT3-fs: sdb1: couldn't mount because of unsupported optional > features (2). > - s n i p - > > I tried using fdisk instead. Note that fdisk finds a different > partition table than cfdisk above! > > - s n i p - > [EMAIL PROTECTED]:~# fdisk -l /dev/sdb > /dev/sdb > #type name length base ( > size ) system > /dev/sdb1Apple_partitiooma}amamamamamama Apple 63 @ 1 > ( 31.5k) Unknown > /dev/sdb2Apple_gee_e_e_e_e_e_ [EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL > PROTECTED]@.%G�%@ 781434611 @ 781397715 (372.6G) Unknown > Well, that certainly looks like an apple partition map has been there at some time - you definitely can't use fdisk from util-linux on it. > Block size=512, Number of Blocks=781422768 > DeviceType=0x0, DeviceId=0x0 > > [EMAIL PROTECTED]:~# dd if=/dev/zero of=/dev/sdb count=1 > 1+0 records in > 1+0 records out > 512 bytes (5.1 MB) copied, 0.366181 seconds, 14.0 MB/s > [EMAIL PROTECTED]:~# fdisk -l /dev/sdb > [EMAIL PROTECTED]:~# cfdisk -P s /dev/sdb > FATAL ERROR: No partition table. > And I think that just says that cfdisk is looking for a dos partition table. Please try parted. Ken -- das eine Mal als Tragödie, das andere Mal als Farce - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Weird harddisk behaviour
On Wed, Jan 17, 2007 at 11:09:21AM +0100, Turbo Fredriksson wrote: > Quoting Ken Moffat <[EMAIL PROTECTED]>: > > > Certainly, fdisk from util-linux doesn't know about mac disks, and > > I thought the same was true for cfdisk and sfdisk. Many years ago > > there was mac-fdisk, I think also known as pdisk, but nowadays the > > common tool for partitioning mac disks is probably parted. > > Yes. See now that 'fdisk' is a softlink to 'mac-fdisk'... > Sorry for not replying earlier, cutting the Cc: list on lkml is not always conducive to quick replies. So, you were using a valid tool, but what you put in your original mail shows garbage - something like apple_partition_ma[mamama... followed later by some garbage which could admittedly have been UTF-8 getting trashed in the mail. I'm on my ibook at the moment, which has an old debian mac-fdisk on another partition. If I chroot to that and look at the disk I see things like /dev/hda #type name length base ( size ) system /dev/hda1 Apple_partition_map Apple63 @ 1( 31.5k) Partition map /dev/hda2 Apple_Bootstrap untitled 1954 @ 64 (977.0k) NewWorld bootblock and so forth. Notice that everything there is in legible ascii and can be read with sensible values. If what you actually see is similar, then it's just a problem in the mail. But if it isn't, somehow the data on the disk (or the data being read from it) is corrupt. ĸen -- das eine Mal als Tragödie, das andere Mal als Farce - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.18-stable release plans?
On Wed, Jan 24, 2007 at 11:45:57PM +, Chris Rankin wrote: > > There is a world of difference between a polite request for more information > (although I gave you > everything I had), and fobbing someone off with a story about cosmic rays. > Chris, I doubt there was a single version of the kernel which ever worked well for all its users. In a production environment, reverting to an older version may be the best short-term answer, but if nobody recognises the problem you won't get any closer to a proper fix. At the moment, you have a problem that nobody recognises. If you're not willing to test if the problem happens repeatably, (you appear to have had one failure and immediately reverted to an old kernel), who do you think will be able to fix it? And if it turns out it doesn't fail repeatably, maybe the responses you've received could be correct. The stable team are only there to maintain the current release of the kernel. There is no maintenance of earlier releases (except Adrian's work on 2.6.16), other than what a distro chooses to do to backport fixes. Of course, if the problem _is_ reproducible on your machine and config, you might get asked to try to identify when it got introduced (e.g. was 2.6.19 itself, or an arbitrary 2.6.19-rc, ok?). Ken -- das eine Mal als Tragödie, das andere Mal als Farce - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.18-stable release plans?
On Thu, Jan 25, 2007 at 09:16:04AM +, Chris Rankin wrote: > > But anyway - can someone please tell me what "Eeek! page_mapcount(page) went > negative! (-1)" is > *really* saying/implying? Because I am currently translating this as "I WANT > TO EAT YOUR > FILESYSTEMS". > I can't, but Dave Jones had a similar problem earlier this month, archived at http://uwsg.iu.edu/hypermail/linux/kernel/0701.0/1822.html which I think is a followup from http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg105370.html - and seems to be a possible hardware failure (bulging capacitors) becoming apparent under load. Ken -- das eine Mal als Tragödie, das andere Mal als Farce - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: x86 instability with 2.6.1{8,9}
On Mon, Jan 15, 2007 at 04:29:11PM +, Ken Moffat wrote: > > Today, I've built 2.6.19.2 without highmem (the box only has 1GB, > dunno why I'd included that in the original config) and I will > continue to wait patiently for either a week without problems, or > something that I can manage to note - although I think at the moment > that the second coming of the great prophet Zarquon is more likely. > Bizarre - it panic'd again last Thursday while I was in X, but I still didn't manage to log any output. At the weekend, I had the bright idea of using chattr +j on the syslog to try to journal any data, since then it has been fine. So, it isn't down to highmem, and I still can't trigger it reliably, or get any trace. Tried running as x86_64 this morning (because cold starts on Thursdays seem particularly problematic, perhaps it's a time/power-supply-noise problem), then x86 from a cold start this afternoon. Time to hope it won't bite me too often, and move on to testing 2.6.20-rc6. Ken -- das eine Mal als Tragödie, das andere Mal als Farce - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: compile failure on 2.6.19
On Sun, Dec 31, 2006 at 10:27:26AM -0800, David Brown wrote:
> On 12/31/06, Robin Cook <[EMAIL PROTECTED]> wrote:
> >I am getting this error when I try to compile 2.6.19 and 2.6.19.1.
> >
> >I ran make mrproper and make menuconfig then ran make and got the below
> >error.
> >
> > HOSTLD scripts/kconfig/conf
> >scripts/kconfig/conf -s arch/i386/Kconfig
> > CHK include/linux/version.h
> > UPD include/linux/version.h
> >/bin/sh: -c: line 0: syntax error near unexpected token `('
> >/bin/sh: -c: line 0: `set -e; echo ' CHK
> >include/linux/utsrelease.h'; mkdir -p include/linux/; if [ `echo -n
> >"2.6.19.1 .file null .ident
> >GCC:(GNU)4.1.1 .section .note.GNU-stack,,@progbits" | wc -c ` -gt 64 ];
> >then echo '"2.6.19.1 .file null .ident
> >GCC:(GNU)4.1.1 .section .note.GNU-stack,,@progbits" exceeds 64
> >characters' >&2; exit 1; fi; (echo \#define UTS_RELEASE \"2.6.19.1 .file
> >null .ident GCC:(GNU)4.1.1 .section .note.GNU-stack,,@progbits\";) <
> >include/config/kernel.release > include/linux/utsrelease.h.tmp; if [ -r
> >include/linux/utsrelease.h ] && cmp -s include/linux/utsrelease.h
> >include/linux/utsrelease.h.tmp; then rm -f
> >include/linux/utsrelease.h.tmp; else echo ' UPD
> >include/linux/utsrelease.h'; mv -f include/linux/utsrelease.h.tmp
> >include/linux/utsrelease.h; fi'
> >make: *** [include/linux/utsrelease.h] Error 2
>
> I'd check /dev/null and make sure it's not a regular file this
> happened to me a while back
>
> - David Brown
If that doesn't fix it, I suspect it's a shell problem (e.g.
bash-3.{1,2} without all the patches). I've seen a number of
issues with bash in the past few months, sometimes it highlighted
code that needed to be fixed, other times it tripped over
parentheses.
Ken
--
das eine Mal als Tragödie, das andere Mal als Farce
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
x86 instability with 2.6.1{8,9}
Hi, I've been running an athlon64 in 64-bit mode without problems, up to and incluing 2.6.19.1. A couple of weeks ago I decided to use it for testing x86 builds, since then it's been nothing but trouble in 32-bit mode. It still works fine when I boot it in 64-bit mode. I already had a 32-bit system on the disk, but it was somewhat old (gcc-3.4.6, udev from a long while ago, glibc-2.3.4) so I wasn't totally surprised when it started to spontaneously reboot. Eventually, I installed a recent system to build a fresh 32-bit system. Still suffered from reboots - sometimes within a few minutes of booting, sometimes it was fine for hours. Tried various versions of 2.6.18.x, eventually thought it was ok, built my new system in several stages. On Saturday it was running the fresh system under 2.6.18.6 for most of the day without problems (although admittedly the first part was from the console, and only the last 2 or 3 hours were running X). Yesterday I left it building arts, and it rebooted. It was then able to finish building much of kde, and then built 2.6.19.1. Booted into 2.6.19.1, spent several hours using the desktop and running compiles and tests. Today, in 2.6.19.1, the keyboard LEDs for caps and scroll lock started flashing about 30 minutes after I'd booted it, so I guess it had oopsed. Unfortunately, nothing from the oops made it to the logs, although SysRq+b worked, so I guess I need to look at the SysRq options before it happens again. So, at the moment I've still got nothing in the logs from any of this, and it isn't predictable. This all happens while running X (originally 6.8.2, now 7.1). I'm beginning to despair of getting any indications about what is going wrong. Any suggestions, please ? Current ver_linux and config follow. Ken If some fields are empty or look unusual you may have an old version. Compare to the current minimal requirements in Documentation/Changes. Linux bluesbreaker 2.6.19.1 #1 PREEMPT Sun Dec 31 17:44:47 GMT 2006 i686 athlon-4 i386 GNU/Linux Gnu C 4.1.1 Gnu make 3.81 binutils 2.17 util-linux 2.12r mount 2.12r module-init-tools 3.2.2 e2fsprogs 1.39 Linux C Library> libc.2.5 Dynamic linker (ldd) 2.5 Linux C++ Library 6.0.8 Procps 3.2.7 Kbd1.12 Sh-utils 6.6 udev 103 Modules Loaded snd_via82xx snd_mpu401_uart r8169 snd_rawmidi # # Automatically generated make config: don't edit # Linux kernel version: 2.6.19.1 # Sun Dec 31 17:37:29 2006 # CONFIG_X86_32=y CONFIG_GENERIC_TIME=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_X86=y CONFIG_MMU=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION="" # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y # CONFIG_IPC_NS is not set CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_UTS_NS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y # CONFIG_RELAY is not set CONFIG_INITRAMFS_SOURCE="" CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_SLAB=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # CONFIG_SLOB is not set # # Loadable module support # CONFIG_MODULES=y # CONFIG_MODULE_UNLOAD is not set # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y # # Block layer # CONFIG_BLOCK=y CONFIG_LBD=y # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_LSF is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="cfq" # # Processor type and features # # CONFIG_SMP is not set CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_
Re: x86 instability with 2.6.1{8,9}
On Mon, Jan 01, 2007 at 04:48:55PM +, Alistair John Strachan wrote: > > Obviously papering over a severe bug, but why is it necessary for you to run > a > 32bit kernel to test 32bit userspace? If your 64bit kernel is stable, use the > IA32 emulation surely? > My 64-bit is pure64 on this machine, so it doesn't have any suitable libs or tools. Anyway, I really do need a 32-bit kernel to test some linuxfromscratch build instructions. Ken -- das eine Mal als Tragödie, das andere Mal als Farce - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: x86 instability with 2.6.1{8,9}
On Mon, Jan 01, 2007 at 05:07:58PM +, Ken Moffat wrote: > On Mon, Jan 01, 2007 at 04:48:55PM +, Alistair John Strachan wrote: > > > > Obviously papering over a severe bug, but why is it necessary for you to > > run a > > 32bit kernel to test 32bit userspace? If your 64bit kernel is stable, use > > the > > IA32 emulation surely? > > > My 64-bit is pure64 on this machine, so it doesn't have any > suitable libs or tools. Anyway, I really do need a 32-bit kernel > to test some linuxfromscratch build instructions. > Sorry, I think last night is still interfering with my own logic circuits. Yes, I could use 'linux32' to change the personality as a work-around now that I've built the system. Mainly, I was hoping somebody would notice something bad in the config, but I might use the work-around in the meantime. Thanks for reminding me about it. Ken -- das eine Mal als Tragödie, das andere Mal als Farce - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: x86 instability with 2.6.1{8,9}
On Tue, Jan 02, 2007 at 12:25:57PM -0500, Len Brown wrote: > > it's been nothing but trouble in 32-bit mode. > > It still works fine when I boot it in 64-bit mode. > > A shot in the dark at the spontaneous reset issue, but no clue on the 32 vs > 64-bit observation... > > See if ACPI exports any temperature readings under > /proc/acpi/thermal_zone/*/temperature > and if so, keep an eye on them to see if there is an indication of a thermal > problem. > > ( And if ACPI doesn't, maybe lmsensors can find something.) > > cheers, > -Len Thanks, but there is nothing there. I never managed to get lmsensors configured (as in 'calibrated') for the hardware I tried it on, but I was starting to think about retrying it. But first, I'm just about to start testing with memtest86+ in case something in the memory has gone bad. ĸen -- das eine Mal als Tragödie, das andere Mal als Farce - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: x86 instability with 2.6.1{8,9}
On Tue, Jan 02, 2007 at 01:42:32PM -0500, Len Brown wrote: > > You might remove and re-insert the DIMMS. > Sometimes there are poor contacts if the DIMMS are not fully seated and > clicked in. > > The real mystery is the 32 vs 64-bit thing. > Are the devices configured the same way -- ie are they both in IOAPIC mode > and /proc/interrupts looks the same for both modes? > > -Len Too late, I've started memtest-86+. If it seems ok after an overnight run, I'll take a look at /proc/interrupts. How can I tell it is in IOAPIC mode, please ? Google was not helpful for this, but if it's an override, the only things on my command lines are root= and video= settings. Certainly, it seems likely that the configs could be fairly different in their detail. Ken -- das eine Mal als Tragödie, das andere Mal als Farce - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: x86 instability with 2.6.1{8,9}
On Wed, Jan 31, 2007 at 04:36:30PM -0500, Chuck Ebbert wrote: > Ken Moffat wrote: > > On Mon, Jan 15, 2007 at 04:29:11PM +0000, Ken Moffat wrote: > > > > Bizarre - it panic'd again last Thursday while I was in X, but I > > still didn't manage to log any output. At the weekend, I had the > > bright idea of using chattr +j on the syslog to try to journal any > > data, since then it has been fine. So, it isn't down to highmem, and > > I still can't trigger it reliably, or get any trace. Tried running > > as x86_64 this morning (because cold starts on Thursdays seem > > particularly problematic, perhaps it's a time/power-supply-noise > > problem), then x86 from a cold start this afternoon. > > > > Time to hope it won't bite me too often, and move on to testing > > 2.6.20-rc6. > > > > Ken > > > Try disabling preempt. Thanks for the suggestion - any particular reason ? That box is running as 64-bit at the moment, and likely to stay that way for the rest of this week while it builds userspace, but I'm not averse to running 32-bit on it again if it serves a purpose. However, in the vain hope I can actually get it to log something, wouldn't it be more useful to continue running _with_ preempt ? I'm starting to think it might have been yet another victim of the solar flares, and the fact it was always running a 32-bit kernel could have been coincidence. Ken -- das eine Mal als Tragödie, das andere Mal als Farce - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
CD oddities with VIA PATA
I'm testing 2.6.19 on this box, and I thought I might as well try out the Parallel ATA driver for the CD/DVD writer (VIA) since the disk is already handled by libata. So far, I've found two oddities - (i.) cdparanoia (9.8) works for root, but for a user it complains that the ioctl isn't cooked and refuses to run. For test purposes, it runs ok for a user as suid root, but I imagine that increases the likelihood of unspeakable things happening. (Fortunately, I don't have a dachshund) (ii.) As a user, I burned a small (28MB) CD using dvdrecord from dvdrtools-0.3.1, and on a different box I can mount it (using ide-cd) and it seems fine. On this box I can't mount it - [EMAIL PROTECTED] ~ $mount /media/cdrom/ mount: wrong fs type, bad option, bad superblock on /dev/cdrom, missing codepage or other error In some cases useful info is found in syslog - try dmesg | tail or so The syslog shows Dec 1 21:17:41 ac30 kernel: attempt to access beyond end of device Dec 1 21:17:41 ac30 kernel: sr0: rw=0, want=68, limit=4 Dec 1 21:17:41 ac30 kernel: isofs_fill_super: bread failed, dev=sr0, iso_blknum=16, block=16 The iso is the gparted-livecd-0.3.1-1.iso. The problem might be specific to small CDs, I can mount others (41M of data and more) without difficulty and all of the likely NLS options are selected as =y in my config. Ken -- das eine Mal als Tragödie, das andere Mal als Farce - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: CD oddities with VIA PATA
On Fri, Dec 01, 2006 at 10:01:34PM +, Ken Moffat wrote: > > (i.) cdparanoia (9.8) works for root, but for a user it complains > that the ioctl isn't cooked and refuses to run. For test purposes, > it runs ok for a user as suid root, but I imagine that increases > the likelihood of unspeakable things happening. (Fortunately, I > don't have a dachshund) > Forgot to mention the lines in the log from cdparanoia, but I think these frequent messages are expected: Dec 1 20:35:53 ac30 kernel: sg_write: data in/out 30576/30576 bytes for SCSI command 0xbe--guessing data in; Dec 1 20:35:53 ac30 kernel:program cdparanoia not setting count and/or reply_len properly Also forgot the details of the drive, just in case Dec 1 19:17:14 ac30 kernel: scsi3 : pata_via Dec 1 19:17:14 ac30 kernel: ata4.00: ATAPI, max UDMA/66 Dec 1 19:17:14 ac30 kernel: Losing some ticks... checking if CPU frequency changed. Dec 1 19:17:14 ac30 kernel: ata4.00: configured for UDMA/66 Dec 1 19:17:14 ac30 kernel: scsi 3:0:0:0: CD-ROMLITE-ON DVDRW SHW-1635S YS0G PQ: 0 ANSI: 5 Dec 1 19:17:14 ac30 kernel: sr0: scsi3-mmc drive: 48x/48x writer cd/rw xa/form2 cdda tray Dec 1 19:17:14 ac30 kernel: Uniform CD-ROM driver Revision: 3.20 Dec 1 19:17:14 ac30 kernel: sr 3:0:0:0: Attached scsi CD-ROM sr0 Dec 1 19:17:14 ac30 kernel: sr 3:0:0:0: Attached scsi generic sg1 type 5 Ken -- das eine Mal als Tragödie, das andere Mal als Farce - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: CD oddities with VIA PATA
On Sun, Dec 03, 2006 at 09:03:53PM -0800, Joshua Kwan wrote: > On 12/01/2006 02:42 PM, Ken Moffat wrote: > > On Fri, Dec 01, 2006 at 10:01:34PM +0000, Ken Moffat wrote: > >> (i.) cdparanoia (9.8) works for root, but for a user it complains > >> that the ioctl isn't cooked and refuses to run. For test purposes, > >> it runs ok for a user as suid root, but I imagine that increases > >> the likelihood of unspeakable things happening. (Fortunately, I > >> don't have a dachshund) > > For the record, > cdparanoia III release 10pre0 (August 29, 2006) > > works for me. My particular IDE adapter is: > > 00:0f.1 IDE interface: VIA Technologies, Inc. > VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) > (prog-if 8a [Master SecP PriP]) > > I have not tried older versions (yet). Could you try this and see if > things are still broken? > > -- > Joshua Kwan > I had tried it, but it turns out my trial used the old installed libcdda_* libraries. Now that I've got it using the new versions of these, it looks as if 10pre0, with the debian patches, works ok for a normal user (on x86_64 it needs the patch to be able to configure). Thanks for the pointer. FWIW I can no longer replicate the failure to mount a CD it had burned, will be doing more tests later. Ken -- das eine Mal als Tragödie, das andere Mal als Farce - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: x86 instability with 2.6.1{8,9}
On Sat, Jan 06, 2007 at 02:04:59PM -0800, Randy Dunlap wrote:
> On Tue, 2 Jan 2007 19:34:59 +0000 Ken Moffat wrote:
>
> > On Tue, Jan 02, 2007 at 01:42:32PM -0500, Len Brown wrote:
> > >
> > > You might remove and re-insert the DIMMS.
> > > Sometimes there are poor contacts if the DIMMS are not fully seated and
> > > clicked in.
> > >
> > > The real mystery is the 32 vs 64-bit thing.
> > > Are the devices configured the same way -- ie are they both in IOAPIC mode
> > > and /proc/interrupts looks the same for both modes?
> > >
> > > -Len
> >
> > Too late, I've started memtest-86+. If it seems ok after an
> > overnight run, I'll take a look at /proc/interrupts. How can I tell
> > it is in IOAPIC mode, please ? Google was not helpful for this, but
> > if it's an override, the only things on my command lines are root=
> > and video= settings.
>
> (did anyone ever answer this?)
>
> In IO-APIC mode, /proc/interrupts contains entries like these:
>
>CPU0 CPU1
> 0: 121218123 0IO-APIC-edge timer
> 1: 715259 0IO-APIC-edge i8042
> 6: 5 0IO-APIC-edge floppy
> 7: 0 0IO-APIC-edge parport0
> 9: 0 0 IO-APIC-level acpi
> 12: 10011272 0IO-APIC-edge i8042
> 14: 11561548 0IO-APIC-edge ide0
> 66:4525183 0 PCI-MSI libata
> 74: 1711 0 IO-APIC-level ehci_hcd:usb1, uhci_hcd:usb6
> 82: 4 0 IO-APIC-level ohci_hcd:usb2, ohci_hcd:usb3,
> ohci_hcd:usb4, ohci_hcd:usb5
> 98: 101326 0 PCI-MSI HDA Intel
> 106: 17747181 0 PCI-MSI eth0
> 169: 0 0 IO-APIC-level uhci_hcd:usb9
> 177: 3 0 IO-APIC-level ohci1394
> 185: 15 0 IO-APIC-level uhci_hcd:usb8, aic79xx
> 193: 427962 0 IO-APIC-level uhci_hcd:usb7, aic79xx
>
> If not in IO-APIC mode, lots of those will say "XT-PIC" instead
> of IO-APIC.
>
> > Certainly, it seems likely that the configs could be fairly
> > different in their detail.
>
>
I eventually found it ("Local APIC support on uniprocessors") in
menuconfig. In the meantime, I'd moved my 32-bit activity to a
different box (also athlon64, but a bit faster) and I had one oops
on that. At least, I assume it was an oops - the caps and scroll
LEDs flashed, but I couldn't do anything with MagicSysrq, not even
force a reboot. Ran diff on the various configs, changed to IO-APIC
plus an unrelated change to use libata for the cdrom. The faster box
_seems_ stable (used for a couple of hours, and then for a whole day)
so I'm back on the original problem machine.
Last night I reconfigured the kernel (select X86_UP_APIC, deselect
ACPI_VIDEO [ had been a module ], select ACPI_DEBUG, select PCI_MSI
(had been on in my 64-bit configs), removed some ATA/ATAPI drivers I
didn't need). I was running on the 'old' 2.6.19.1 while I built it,
and again got the flashing LEDs after the build, but nothing logged
although I was able to force a reboot with SysRq b.
I guess that when it does have problems, it is mostly within 30
minutes of booting - otherwise, it can be up all day. So, for the
moment I'm hopeful that changing the config will help, but it will
be several days before I feel at all confident.
Ken
--
das eine Mal als Tragödie, das andere Mal als Farce
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: OT: character encodings (was: Linux 2.6.20-rc4)
On Mon, Jan 08, 2007 at 09:17:06PM +0100, Jan Engelhardt wrote: > > On Jan 8 2007 02:22, Jan Engelhardt wrote: > >On Jan 7 2007 22:30, Alan wrote: > >> > >>> >The kernel maintainers/help/config pretty consistently use UTF8 > >>> > >>> I've seen a lot of places that don't do so. Want a patch? > >> > >>I think that would be a good idea - and add it to the coding/docs specs > >>that documentation is UTF-8. Code should IMHO say 7bit though. > > Most memorable issues: > > * "dont" (standalone accent aigu) rather than "don't" > (apostrophe) > * "", non breaking spaces > * cp437 encoding in some files (heh, heh, DOS!) > * iso8859-1/utf-8 mixed in some files Looks nicely done, but I query the postal address changes in Documentation/cdrom/sbpcd - that seems to be a change of address (without anything to explain it). Everything else seems to be just character-set conversion or the occasional translation of comments into English. (And no, I didn't attempt to review the character-set changes, even it there is an occasional error it will be better than where we are now, and easy to patch.) > > My compose key is hot now... I prefer the AltGr dead keys in X (they seem to work more reliably for me), but I guess I'm straying OT. > > None of you people screw that patch with your buggy MUAs! I'll pack > it up into a .bz2 to get it marked as application/octet-stream to > not even give your MUA the chance to. ;-) [and because it's 221 K > uncompressed and I am not sure if splitting it up makes much sense for > such 'trivial' changes, or not?] > > Signed-off-by: Jan Engelhardt <[EMAIL PROTECTED]> > > > -`J' > -- Thanks for doing this, I hope it wasn't in vain. Ken -- das eine Mal als Tragödie, das andere Mal als Farce - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel utf-8 handling
On Fri, Jun 01, 2007 at 04:20:58PM +0200, DervishD wrote: > Hi all :) > > I have a do-it-yourself Linux box, and I'm planning to move to UTF8 > (currently I'm using es_ES locale, with latin1 encoding). One of my main > concerns (apart from programs with little or no utf8 support, which I > will have to suffer) is kernel handling, because I only use the console; > I only use X and a terminal emulator if I can't avoid it. > [...] > > Will the console work as it works now if I can live with latin1 > accented characters only? Is there any terminal emulator *for the > console*, not for X, that handles utf8? Will I be sentenced to X to be > able to use my computer with utf8? > Sure, the console will work (don't know about a console terminal emulator). I'm not very keen on compose keys - I find dead diacriticals (like in X) are usually easier to enter, and I've got all the dead latin1 accents working on my uk keymap. Other diacriticals for normally-latin1 keymaps are a different matter (e.g. caron, ogonek, dot above) - they could be mapped for a specific letter on a specific key (e.g. AltGr z for ż ; z with dot above) but the diacritical modifiers can't be mapped for non latin1, at least in kbd-1.12. You can also alter the keymap to allow you do ISO 14755 input (ctrl+shift+hex_digits) - useful for occasional characters, if they are in your font and you can remember their value. Ken -- das eine Mal als Tragödie, das andere Mal als Farce - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
New version of shutdown?
I've just shut down -rc1 on my ppc64, and got a big scary message from the following code in libata-scsi.c: ata_dev_printk(qc->dev, KERN_WARNING, "DISK MIGHT NOT BE SPUN DOWN PROPERLY. " "UPDATE SHUTDOWN UTILITY\n"); So, I went to http://linux-ata.org/shutdown.html, but as far as I can make out, every distro is expected to reinvent the wheel by altering shutdown themselves. For those of us who build from source, (e.g sysvinit-2.86) is there an example of an up-to-date released version of shutdown ? Ken -- das eine Mal als Tragödie, das andere Mal als Farce - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Lockup after logging out of X
This is a resend, with a better title and slightly more
clarification. Originally sent yesterday evening, but I can see no
evidence that it got beyond my isp's mailserver. Apologies to the
Cc's if you did get the original.
Using Linus' tree pulled on Sunday afternoon UK time. Running an
amd64 ('pure64') desktop using gdm for graphical login, on Xorg 7.2
with a radeon 9200se. No problems until I log out of the desktop
and go back to gdm. Before that, the text consoles seem to be
working fine. After I go back to gdm. the display is corrupted and
only MagicSysRQ works. Mostly, the keyboard LEDs flash, but the
only thing that made it to the logs was this exceedingly incomplete
oops report:
May 7 21:02:54 bluesbreaker kernel: [ 46.549615] [drm] writeback
test succeeded in 1 usecs
May 7 21:03:24 bluesbreaker kernel: [ 61.552793] Unable to handle
kernel paging request at 81003befd3e8 RIP:
May 7 21:03:24 bluesbreaker kernel: [ 61.552798]
[] fasync_helper+0x52/0xf0
May 7 21:03:24 bluesbreaker kernel: [ 61.552805] PGD 8063 PUD
9063 PMD 80003bef11e3 BAD
May 7 21:03:24 bluesbreaker kernel: [ 61.552811] Oops: 0009 [1]
PREEMPT
May 7 21:04:18 bluesbreaker syslogd 1.4.1: restart.
After trying git-bisect, it tells me:
0dbf7028c0c1f266c9631139450a1502d3cd457e is first bad commit
commit 0dbf7028c0c1f266c9631139450a1502d3cd457e
Author: Vivek Goyal <[EMAIL PROTECTED]>
Date: Wed May 2 19:27:07 2007 +0200
[PATCH] x86: __pa and __pa_symbol address space separation
Currently __pa_symbol is for use with symbols in the kernel
address
map and __pa is for use with pointers into the physical memory
map.
But the code is implemented so you can usually interchange the
two.
__pa which is much more common can be implemented much more
cheaply
if it is it doesn't have to worry about any other kernel address
spaces. This is especially true with a relocatable kernel as
__pa_symbol needs to peform an extra variable read to resolve
the address.
[snip the rest of the commit message on the resend]
This time, I'll gzip the config in case it was a size problem for
the list.
Ken
--
das eine Mal als Tragödie, das andere Mal als Farce
config.amd64.gz
Description: application/gunzip
Re: Lockup after logging out of X
On Tue, May 08, 2007 at 04:21:51PM -0400, [EMAIL PROTECTED] wrote: > On Tue, 08 May 2007 20:51:42 BST, Ken Moffat said: > > > After trying git-bisect, it tells me: > > 0dbf7028c0c1f266c9631139450a1502d3cd457e is first bad commit > > commit 0dbf7028c0c1f266c9631139450a1502d3cd457e > > Author: Vivek Goyal <[EMAIL PROTECTED]> > > Date: Wed May 2 19:27:07 2007 +0200 > > > > [PATCH] x86: __pa and __pa_symbol address space separation [...] > > I saw this same exact problem on my box back at 21-rc5-mm4, but didn't > report it here because Christoph Hellwig thinks such things are off-topic (as > I was seeing it with the NVidia driver). > > http://marc.info/?l=linux-kernel&m=117579249300455&w=2 > http://www.nvnews.net/vbulletin/showthread.php?t=89444 > > Sorry to see you hit a problem with the exact same patch with a Radeon card > a month later. > OK, in view of the minimal oops output that made it to my log (forgot to say in today's repost that it was from one of the bad bisect builds), I'd better point out that I don't have the ati module (fglrx or whatever it is called), this is purely using Linus' tree. Ken -- das eine Mal als Tragödie, das andere Mal als Farce - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Lockup after logging out of X
On Wed, May 09, 2007 at 12:47:02AM +0200, Michal Piotrowski wrote: > > Please check the latest -git. > > 31 hours ago Linus Torvalds Revert "[PATCH] x86: __pa and > __pa_symbol address space ... > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=e3ebadd95cb621e2c7436f3d3646447ac9d5c16d Thanks. > > Regards, > Michal > > -- > Michal K. K. Piotrowski > Kernel Monkeys > (http://kernel.wikidot.com/start) -- das eine Mal als Tragödie, das andere Mal als Farce - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Lockup after logging out of X
On Wed, May 09, 2007 at 01:01:34AM +0200, Andi Kleen wrote: > > Already known, although it is still unclear what the bug actually is. > Can you run with the appended patch please (from Eric Biederman) > and post any backtraces the WARN_ON in there spews out? > > Also do you use swiotlb? > > Thanks > > -Andi > Had to turn off modules to get it to build. It half-logged another oops, but no backtraces, and SysRq+r does nothing. Nothing else unusual in the log. May 9 00:47:12 bluesbreaker gconfd (ken-2833): Resolved address "xml:readonly:/etc/gnome/gconf/gconf.xml.defaults" to a read-only configuration source at position 2 May 9 00:52:59 bluesbreaker kernel: [ 275.667737] Unable to handle kernel paging request at 81003b4ac3e8 RIP: May 9 00:52:59 bluesbreaker kernel: [ 275.667742] [] fasync_helper+0x52/0xf0 May 9 00:52:59 bluesbreaker kernel: [ 275.667749] PGD 8063 PUD 9063 PMD 80003b4a11e3 BAD May 9 00:52:59 bluesbreaker kernel: [ 275.667754] Oops: 0009 [1] PREEMPT May 9 00:54:26 bluesbreaker syslogd 1.4.1: restart. May 9 00:54:26 bluesbreaker bootlog: Starting system log daemon... [ OK ] Apparently I do use swiotlb - I didn't know that, and can't see where it gets asked in menuconfig, but I can see CONFIG_SWIOTLB=y Let me know if there is anything else I can test (probably pm tomorrow), otherwise I'll go back to -head. Ken -- das eine Mal als Tragödie, das andere Mal als Farce - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: 2.6.20-1 not working on ibook g4 (BUG/Oops)
On Mon, Mar 05, 2007 at 04:59:35PM +0100, francesco foresti wrote: > Hi, > I have to correct myself: > 2.6.19-7 just freezes randomly. At this point, the last surely working kernel > i am aware of is 2.6.18, built from debian sources. Actually i'm trying > (for the very first time) to git-bisect Linus' tree, to see if i can figure > out something, but i feel my chances are extremely low.. > > Best > -- Sounds like a distro problem. In particular, distros add patches and use different configs. My ibook G4 has been running 2.6.20-rc4 since about January 8th without any issues, but I can remember that it took me a very long time to come up with a .config which worked for me after the move to arch/powerpc. If your graphics card is a radeon, I can send you my .config off-list if you think that will help. Ken -- das eine Mal als Tragödie, das andere Mal als Farce - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: mmap error?
Hi Gene, On Mon, Apr 02, 2007 at 10:30:29AM -0400, Gene Heskett wrote: > Greetings all; > > Has something been changed recently, say post 2.6.19, that would effect > this error from k3b when I click start (the burn), with a fresh dvd+r in > the drive: > > > Using growisofs 7.0 Copyright (C) Andy Polyakov <[EMAIL PROTECTED]> > Starting writing... > :-( unable to anonymously mmap 33554432; resource temporarily > unavailable... > Fatal error at startup, resource temporarily unavailable... > Known problem, please see http://fy.chalmers.se/~appro/linux/DVD+RW/tools/ (third paragraph) for a workaround. ĸen -- das eine Mal als Tragödie, das andere Mal als Farce - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: console font limits
On Tue, May 01, 2007 at 12:09:46AM -0400, Albert Cahalan wrote: > > BTW, the PSF font format documentation seems to suggest that > there is a way to make the kernel handle combining accents: > http://www.win.tue.nl/~aeb/linux/kbd/font-formats-1.html > Does anybody know if that really works? I could sure use that. My reading of it suggests you need a precomposed version to which the combining combination can be mapped (the 00c5 for Å in the example). Possibly, the fffe and are used as delimiters for the combination). Maybe, it could be used for yoruba (yeah, I was looking at that an hour before I read your mails) _if_ the font has room to fit in a "private use" character which can hold the precomposed value. For any letter where a precomposed version is in the unicode standards, the only use for combining characters in a console font seems to be as a way of displaying text where somebody has already used them. For latin languages which need additional composed letters, the bigger problem will probably be the input - I've no idea if the console keymap can use combining keys (direct input of the unicode hex is available, of course), and I can't manage to get the direct input of the codes for combining diacriticals to work in combination in my preferred graphical terminal. Ken -- das eine Mal als Tragödie, das andere Mal als Farce - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Lockups with 4.2-rc kernels and qemu
On Thu, Aug 27, 2015 at 05:52:58PM +0100, Ken Moffat wrote: > On Thu, Aug 27, 2015 at 12:59:14PM +0100, Ken Moffat wrote: > > On Tue, Aug 25, 2015 at 12:40:15AM +0100, Ken Moffat wrote: > > > (Cc'ing qemu-devel, please keep me in the Cc). > > > > > > TL;DR - qemu locks up my machine when I use 4.2-rc kernels. > > > > > Previous mail, or at least the copy to qemu, archived at > > https://lists.gnu.org/archive/html/qemu-devel/2015-08/msg02784.html > > > > I started bisecting, but it is going to be a slow business - kernels > > which seem to be ok after e.g. 3 hours can still lock the box. I > > left it running overnight, and this morning it was still up - but > > firefox could no longer connect externally. I eventually tracked > > that to my logs taking the space. But one reason the logs had > > become so big was the following (found from this morning's restart): > > > > Aug 27 09:50:28 ac4tv kernel: [ 124.279813] BUG: scheduling while > > atomic: qemu-system-x86/1789/0x0002 > > Aug 27 09:50:28 ac4tv kernel: [ 124.279819] Modules linked in: > > psmouse i2c_piix4 asus_atk0110 microcode k10temp > > Aug 27 09:50:28 ac4tv kernel: [ 124.279828] Preemption disabled > > at:[] kvm_vcpu_ioctl+0x7c/0x580 > > This is definitely a *different* bug - I just tried the next kernel, > and started to get these messages (almost 100,000 lines of them in > the next 4 minutes) : if that had been happening a couple of weeks > ago, I would have noticed ;-) > > But, the end result is that I cannot attempt to bisect the lockups, > this scheduling while atomic business is preventing me looking for a > good kernel. > > Has anybody had success qith qemu on an x86_64 host running a 4.2-rc > kernel ? Looks as if I'll have to give up, and hope that the main > problem doe not spread to 4.1. > What will (hopefully) be my last comment on this - I went back to 4.1.3 on the host, and after a couple of hours it locked up. Maybe in the past I have jsut been lucky. I think in future I'll probably stick to native builds., it seems to be less painful. ĸen -- Il Porcupino Nil Sodomy Est! (if you will excuse my latatian) aka "The hedgehog song" -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Recommended driver for current AMD processors
Hi Paul, On Fri, 7 Dec 2018 at 15:32, Paul Menzel wrote: > > Dear Linux folks, > > > What driver is recommended for current AMD Ryzen based processors > like *AMD Ryzen 5 PRO 1500 Quad-Core Processor* or *AMD EPYC 7601 > 32-Core Processor*? > > Only from the acpi-cpufreq Kconfig description, I assume, that that > driver should be used. > > > config X86_ACPI_CPUFREQ > > tristate "ACPI Processor P-States driver" > > depends on ACPI_PROCESSOR > > help > > This driver adds a CPUFreq driver which utilizes the ACPI > > Processor Performance States. > > This driver also supports Intel Enhanced Speedstep and newer > > AMD CPUs. > > > > To compile this driver as a module, choose M here: the > > module will be called acpi-cpufreq. > > > > For details, take a look at . > > > > If in doubt, say N. > > Would a “native” driver like Intel’s P state driver also give better > results? Do you know if AMD is working on something like that? > > > > Kind regards, > > Paul > As a mere user, I bought a ryzen 3 1300X earlier this year, and was annoyed about how the frequencies changed when a single-threaded compile moved to a different core (unlike e.g. a haswell where frequencies barely vary). I have a meter which can report the current power consumption for the system (computer, monitor, network switch, kvm switch), and using that to keep an eye on the range of reported wattages when idle, compiling with -j1 and compiling with -j4, I eventually formed the impression that the ondemand governor was marginally better than the performance governor, and that omitting cpufreq did not appear to increase the poer consumption. But that is just one set of observations. I agree that using less power and getting faster compiles would be nice, so if something is available I'll be keen to try it. ĸen
Re: boot loader
On Tue, Apr 28, 2015 at 08:44:34PM -0300, Thiago Farina wrote: > On Tue, Apr 28, 2015 at 6:49 PM, Richard Weinberger > wrote: > > On Tue, Apr 28, 2015 at 5:12 PM, Thiago Farina wrote: > >> Hi, > >> > >> Does the kernel include a simple boot loader like FreeBSD does? > > > > Why don't you figure yourself? > > > I think it doesn't. I just wanted someone to confirm my thought. > Does the FreeBSD kernel really include a boot loader ? Surely the loader is what reads the kernel into memory and then hands control to it. If you look at FreeBSD as a whole, it has a boot loader for whichever architecture it was built for. But linux is only the kernel - different distros (in this context, android could be regarded as a distro) and most importantly different architectures or platforms all do different things - in my fairly-limited experience I've used grub, lilo, uboot, yaboot - there are many others. But please remember that asking general questions not related to kernel development on this list is generally regarded as off-topic. ĸen -- Nanny Ogg usually went to bed early. After all, she was an old lady. Sometimes she went to bed as early as 6 a.m. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Lost network connectivity in 4.0.x
On Wed, May 27, 2015 at 10:53:00PM -0700, Cong Wang wrote: > (Please always Cc netdev for networking bugs.) > > On Sat, May 23, 2015 at 8:29 PM, Ken Moffat wrote: > > On Sun, May 24, 2015 at 03:43:52AM +0100, Ken Moffat wrote: > >> Anybody else suffering frm lost network connectivity in 4.0.x > >> kernels ? A couple of times this week, vim on an nfs-3 mount hung > >> and I had to reboot. Both of those occasions were on an AMD desktop > >> with the r8169 driver, running 4.0.3. I thought it might be > >> specific to that machine. For the last two or three days I've been > >> using an intel, and about 10 minutes ago it suffered the same problem > >> while running 4.0.4. Using ping from another term showed that it > >> had no connectivity to the server on my local network. > >> > >> This is a bit hard to diagnose - nothing in the logs. > >> > > I forgot to add that this is with the released gcc-5.1 : I keep > > forgetting that some people use old compilers ;-) > > > > Is there any way you can help to narrow down the problem? > Thanks for the reply. The problem is continuing to show up, but irregularly and often only after the machine has been booted for a long time (with s2ram, but I don't think I've used s2ram on every occasion). > For example: > > 1) What is your network setup? iptables? routes? etc. > I'm using iptables. Ah, yes - it started dropping packets around the time I last had a problem: May 27 00:48:26 ac4tv dhclient: DHCPREQUEST on eth0 to 192.168.7.254 port 67 May 27 00:48:27 ac4tv dhclient: DHCPACK from 192.168.7.254 May 27 00:48:27 ac4tv dhclient: bound to 192.168.7.152 -- renewal in 1787 seconds. That address came from my router, and I had been getting the same address for an hour, tbut then the dropped packet messages start appearing - they are for a different address, one that would have been offered by my server: May 27 00:53:16 ac4tv kernel: [31922.316798] IPTABLES Packet Dropped: IN=eth0 OUT= MAC=c8:60:00:97:07:35:bc:ae:c5:57:70:c5:08:00 SRC=192.168.7.11 DST=192.168.7.121 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=2049 DPT=1005 WINDOW=28960 RES=0x00 ACK SYN URGP=0 May 27 00:53:17 ac4tv kernel: [31923.316612] IPTABLES Packet Dropped: IN=eth0 OUT= MAC=c8:60:00:97:07:35:bc:ae:c5:57:70:c5:08:00 SRC=192.168.7.11 DST=192.168.7.121 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=2049 DPT=1005 WINDOW=28960 RES=0x00 ACK SYN URGP=0 and those continued until I forced a reboot. > 2) Can you check the stats to see if there is any error? > `ip -s -s li show`, `ethtool -S ` > I don't have ethtool installed, and that ip command appears ok at the moment: 1: lo: mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 RX: bytes packets errors dropped overrun mcast 3964 66 0 0 0 0 RX errors: length crc frame fifomissed 00 0 0 0 TX: bytes packets errors dropped carrier collsns 3964 66 0 0 0 0 TX errors: aborted fifo window heartbeat transns 00 0 0 0 2: eth0: mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000 link/ether c8:60:00:97:07:35 brd ff:ff:ff:ff:ff:ff RX: bytes packets errors dropped overrun mcast 224661061 277642 0 0 0 0 RX errors: length crc frame fifomissed 00 0 0 0 TX: bytes packets errors dropped carrier collsns 278152429 370438 0 0 0 0 TX errors: aborted fifo window heartbeat transns 00 0 0 6 > 3) Do a bisect? > > Thanks! That doesn't seem very practical when the machine is ok for a couple of days at a time. ĸen -- Nanny Ogg usually went to bed early. After all, she was an old lady. Sometimes she went to bed as early as 6 a.m. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Lost network connectivity in 4.0.x
On Thu, May 28, 2015 at 03:41:49PM +0100, Ken Moffat wrote: > On Wed, May 27, 2015 at 10:53:00PM -0700, Cong Wang wrote: > > (Please always Cc netdev for networking bugs.) > > Sorry, didn't spot that. But anyway > > > For example: > > > > 1) What is your network setup? iptables? routes? etc. > > > I'm using iptables. Ah, yes - it started dropping packets around > the time I last had a problem: > > May 27 00:48:26 ac4tv dhclient: DHCPREQUEST on eth0 to 192.168.7.254 > port 67 > May 27 00:48:27 ac4tv dhclient: DHCPACK from 192.168.7.254 > May 27 00:48:27 ac4tv dhclient: bound to 192.168.7.152 -- renewal in > 1787 seconds. > > That address came from my router, and I had been getting the same > address for an hour, tbut then the dropped packet messages start > appearing - they are for a different address, one that would have > been offered by my server: > Now that I've had time to think about this and look a bit more deeply, I can see that at one point I got a lease from my server, but then after a random length of time the client tried to renew and got a lease from the router. Some time after that, it failed because iptables rejected the nfs packets because they were "not for me". So, not a kernel problem, and the reason I'm (now) seeing this on 4.0+ kernels is that I have not recently booted a system with an old (3.19 or earlier) kernel and kept it running for a long time. Thanks again, sorry to waste everybody's bandwidth. ĸen -- Nanny Ogg usually went to bed early. After all, she was an old lady. Sometimes she went to bed as early as 6 a.m. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
objtool segfault in 5.10 kernels with binutils-2.36.1
Hi, in 5.10 kernels up to and including 5.10.15 when trying to build the kernel for an x86_64 skylake using binutils-2.36.1, gcc-10.2 and glibic-2.33 I get a segfault in objtool if the orc unwinder is enabled. This has already been fixed in 5.11 by ''objtool: Fix seg fault with Clang non-section symbols' https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/patch/?id=44f6a7c0755d8dd453c70557e11687bb080a6f21 So can this be added to 5.10 stable, please ? Please CC me as I am no-longer subscribed. ĸen
3.13.5 : rm -rf running forever, one cpu at approx 100%
Hi, Short summary : on 3.13.5, rm -rf of an application source directory on an ext4 filesystem sometimes takes forever (probably isn't going anywhere), with one CPU pegged at all-but 100% utilization. I've nearly finished building a new system from source, to check various desktop packages in linuxfromscratch. On this build, much of it is things I don't normally use and I needed to upgrade my buildscripts, so most of it was built in chroot using 3.10.32. But late last night I booted the new system using 3.13.5 to finish the build. This morning I discovered that rm -rf for the icedtea source directory was still running, and had taken over 5 hours of CPU time (one CPU seemd to be running at close to 100%, the others had dropped to their slowest frequency). That script was running as root (yeah, but it's a new system) and it looks as if /etc/passwd~ had got trashed, because I could no longer su or login. Not sure if that is related, at this stage it might just be a side-effect of my scripts. Booted another system, chrooted, fixed up passwords. Started again after commenting out icedtea - I hadn't intended to build what was an old version, I'd just forgotten it was in this script - that's why I do things in userspace, not the kernel :-( Continued with remaining packages, but a couple of hours later I saw a similar "one CPU at 100%, rm -rf GConf source taking forever" problem. Dumped all the processes with Alt-SysRQ-T [ huge log ] but at that point 'rm' was merely 'ready' so I doubt there is anything useful to see in the log. Built 3.13.4, booted to that. So far, everything looks good - but I'm now building the _current_ version of icedtea, so if this isn't a new 3.13.5 problem I guess I'm fairly likely to see it tomorrow. Meanwhile, any suggestions about how I can debug this if I hit it again, please ? ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.13.5 : rm -rf running forever, one cpu at approx 100%
On Wed, Feb 26, 2014 at 08:28:29PM -0500, Gene Heskett wrote: > On Wednesday 26 February 2014, Ken Moffat wrote: > > I don't have any help to offer Ken, but this walks and quacks much like a > duck I'm encountering in 3.13.5, with the backup program amanda, which uses > gnu tar. To facilitate intelligent guesses as to the size of the various > levels of backup, amanda does a dummy collection using tar, sent to > /dev/null, using only the size it reports on the first pass. Version 1.22, > quite old, works on 3.12.9, but not on 3.13.5. I have now pulled in, built > and installed tar-1.27, and rebuilt amanda to let it know that the tar its > using is not in /usr/bin, but in /usr/local/bin. Next run at 1:30AM > > This freeze, using 100% of a core, but causing no visible disk activity has > killed my backups 3 nights running. At this point I've no clue as to the > cause, but I will be watching this thread closely, it has a similar > description. > > Cheers, Gene My box where I see this is a phenom (my intel is still on 3.13.4), and from past threads I suspect yours is as well ? ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.13.5 : rm -rf running forever, one cpu at approx 100%
On Thu, Feb 27, 2014 at 04:26:35AM +0100, Mike Galbraith wrote: > > I would start with strace to see if a task is looping in userspace, then > move on to perf top -g -p (or perf record/report) to peek at what > it's up to in the kernel. Once you have the where, trace_printk() is > the best thing since sliced bread (which ranks just below printk()). > > -Mike Thanks. I'll need to build perf. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.13.5 : rm -rf running forever, one cpu at approx 100%
On Thu, Feb 27, 2014 at 05:52:42AM +0100, Mike Galbraith wrote: > On Thu, 2014-02-27 at 03:45 +0000, Ken Moffat wrote: > > On Thu, Feb 27, 2014 at 04:26:35AM +0100, Mike Galbraith wrote: > > > > > > I would start with strace to see if a task is looping in userspace, then > > > move on to perf top -g -p (or perf record/report) to peek at what > > > it's up to in the kernel. Once you have the where, trace_printk() is > > > the best thing since sliced bread (which ranks just below printk()). > > > > > > -Mike > > Thanks. I'll need to build perf. > > You may want to build the kernel with frame-pointers too, for easy gdb > list *0x(hexnum) of *func()+0x(hexoffset) use. Crash is also pretty > handy both for rummaging live via crash vmlinux /proc/kcore, and for > leisurely postmortem analysis if you set the box up to crashdump in > advance, and force a dump (poke sysrq-c or echo c > /proc/sysrq-trigger) > when you see the bad thing happen. Crash has all kinds of goodies, > including invocation of gdb. > > -Mike In fact, it seems I had already enabled perf, but not built the userspace part. However, I was motivated to build crash, and a kernel with frame pointers plus a _lot_ of debug options. Unsurprisingly, that ran like a dog, and many things seemed to use a lot of CPU according to top (e.g. 'X', at least for the first several minutes after it started), but I couldn't replicate the problem. Also proved that my OpenJDK script doesn't normally trash /etc/passwd- :) Then, I went back to the original 3.13.5, proved that perf was working, and built a new LFS system in chroot, again with 3.13.5, in chroot. Booted it as soon as I'd built xorg, then went on through glib/gtk, firefox, print/photo programs, libreoffice. No problems at all, apart from the common "needed to use -j3 for gcc, because it's a phonon". NB I forgot to mention that this is all 64-bit, and the box has 8GB. If something does happen here in the next few days (I've still got to sort out my kde scripts and build that) then I'll reply to this. But otherwise, I guess it must be cosmic rays, or maybe Gaffer forgot to feed and muck-out the imps. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Git v1.9-rc0
On Wed, Jan 22, 2014 at 10:10:18AM -0800, Junio C Hamano wrote: > Vicent Martí writes: > > >> Do these consume CPU every time somebody asks for a tarball? That > >> might be considered "wrong" depending on the view. > > > > No, our infrastructure caches frequently requested tarballs so they > > don't have to be regenerated on the fly. > > Thanks. That is certainly good enough for consumers, and better > than having to manually create and upload for me ;-) Two questions: Does regenerating (e.g. if the tarball has dropped out of the cache) change its sums (md5sum or similar) ? In (beyond) linuxfromscratch we use md5sums to verify that a tarball has not changed. Also, will there be links for manpages and htmldocs tarballs ? I note that all of these *are* still available at googlecode for the moment : https://code.google.com/p/git-core/downloads/list ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Git v1.9-rc0
On Wed, Jan 22, 2014 at 01:04:02PM -0800, Junio C Hamano wrote: > Ken Moffat writes: > > > I note that all of these *are* still available at googlecode for > > the moment : https://code.google.com/p/git-core/downloads/list > > As I said, Cgc is not the ony download site. The end of > > http://git-blame.blogspot.com/p/git-public-repositories.html > > lists the two sites that currently have the material. I may replace > Cgc with something else (and add it/them to the list), but in the > meantime I do not think k.org will go out of business in anytime > soon, so... > OK, thanks for the pointer to https://www.kernel.org/pub/software/scm/git/ for released tarballs. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.15.0-rc2 radeon HD 7480D [Aruba] blank display
On Tue, Apr 22, 2014 at 01:54:01AM -0400, Alex Deucher wrote: > > The attached patch should fix it. > > Thanks, > > Alex > From 9cd764fd57bb2a4e5f618d0f8a64c8154a820688 Mon Sep 17 00:00:00 2001 > From: Alex Deucher > Date: Tue, 22 Apr 2014 01:49:28 -0400 > Subject: [PATCH] drm/radeon/aux: fix hpd assignment for aux bus > Sorry, my default mailbox (the one where personal mail ends up) overflowed (the old "procmail thinks it cannot write to it" issue) and I've been reading mail on my netbook with a short 24-line term, didn't notice that my overflow mailbox had appeared because it was on the next screen. So, sorry for not replying. And then when I did notice, I accidentally sent a personal reply only to Ed. The good news is that -rc3 obviously has the fix, and is working fine. Thanks. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Bug? Older 32 bit program (CivCTP) no longer works under 64 bit kernel
On Thu, May 15, 2014 at 08:24:05PM -0500, David Hagood wrote:
> I have an old native Linux 32 bit copy of Civilization: Call to Power. It
> used to work under a 64 bit environment back in the 3.0.x days. However,
> under recent versions (>3.5) it no longer runs - it complains that it cannot
> find certain files in the directory. The exact same code will run just fine
> under a 32 bit version of 3.11. I have a Pentium II as well as the Core 2
> Duo, both running Ubuntu 14.04, same version of the kernel other than one is
> 32 bit and one is 64 bit. I've copied the files over from the 32 bit
> machine, where it runs, to the 64 bit machine, where it does not. I've even
> gone so far as to copy all the system 32 bit libraries into the CivCTP
> directory, and forced the program to use them (including using the
> ld-linux.so loader from that directory) - so in theory it's all the same
> user space libraries running - the only difference that I can see is that
> one kernel is 64 bit and one is 32 bit.
>
> Running strace on the program shows that the directories being searched for
> game assets are corrupted:
>
> 16218 stat64("/home/wowbaggr/CivCTP/ctdata/englisish/uidata/keymap.txt",
>
>
> Note the "englisish" rather than "english".
>
> I'm looking for any suggestions on where to look for what might cause such
> an issue - what can I do to start tracking this down.
I've no ideas about what part of the kernel is causing this, so
I'll just offer you some thoughts on how to track it down. At a
guess, you will have to run 'git bisect' to nail which change broke
this (or alternatively which change exposed a latent problem).
Bisection is fairly well covered on google, for example it finds
http://landley.net/writing/git-bisect-howto.html
The corrupt filename looks (to me, with no experience) like
something which might be in the filesystem area. It probably isn't,
but I don't recall anything at all like this, so I'd better ask - are
you using an uncommon filesystem for this data ? This looks like
such a grievous fault that I would expect someone to have noticed it
between 3.5.0 and now.
And, have you tried any recent kernels (e.g. 3.14.4) to confirm
that the problem still exists ? If it turns out that somebody
already fixed it, that would save you a lot of effort.
You will need a network connection to clone linus' tree, and some
space for it. And git, of course. To bisect, you should build in
the git tree, AND set CONFIG_LOCALVERSION_AUTO - in
General setup
[ ] Automatically append version information to the version
so that the kernel version, and the version in /lib/modules, will
add -X-g information to each non-release install - that
is useful when you are bisecting, so that each set of modules is
kept separate. See e.g.
http://yarchive.net/comp/linux/CONFIG_LOCALVERSION_AUTO.html
It might speed this up if you can minimise the kernel config
(distros tend to build the whole kitchen sink as modules) - the
fewer unnecessary things you build, the less time it takes.
Does it work on 3.4.0 ? I know 3.4 is supported, and therefore
there are continuing releases with backported fixes, but for
bisection it is easiest to start testing with .0 releases. If it
doesn't work there (I'm unclear if 3.5 was the earliest post-3.0
kernel that you tried), find which was the last .0 kernel where it
worked. You can then label that version as "good", e.g.
git bisect good v3.4 [ or whichever version - without the .0 ].
Once you are certain which .0 version was the last which worked,
the next can be marked as bad, e.g. v3.5 - and then you bisect.
Do not be surprised if the kernel identifies itself as an earlier
version than the last good one - see Linus's post referenced at
yarchive.net above. And good luck, bisection is usually tedious.
ĸen
--
das eine Mal als Tragödie, dieses Mal als Farce
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: More breakage on HD7480D [ Aruba ]
On Tue, May 13, 2014 at 01:22:57PM +0200, Christian König wrote:
> Please try the attached patch it should fix your problem.
>
> Thanks allot for this bug report, that was just a stupid typo in the
> original patch which would probably went unnoticed for years otherwise.
>
> Christian.
>
Thanks, works like a charm. If it adds any utility, feel free to
add
Tested-by: Ken Moffat
ĸen
> Am 12.05.2014 18:32, schrieb Ken Moffat:
> >On Mon, May 12, 2014 at 09:32:54AM +0200, Christian König wrote:
> >>Hi Ken,
> >>
> >>*sigh* did I already mentioned that I hate PLLs? As soon as you fix
> >>something another use case immediately starts to break.
> >>
> >>Please provide dmesg output created with drm.debug=0xe with and without the
> >>patch breaking it.
> >>
> >>Thanks in advance,
> >>Christian.
> >>
> > The reverted version is from linus's tree after -rc5 with the patch
> >reverted, I assume the version -00010-gc9a25d0fc393 will NOT match
> >any public tree because I used git revert in a local branch. That
> >one works fine.
> >
> > The bad version is from a random kernel which showed the problem
> >while I was bisecting, in this case rc2-00086. I first tried
> >booting vanilla rc5, but for some reason my blind attempt to login
> >and run 'dmesg >dmesg.bad' failed.
> >
> > Thanks. Sorry you are having to deal with PLLs.
> >
> >ĸen
>
> >From 8b5c70b48d73b533f0003639cdb68bcffe7c1293 Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Christian=20K=C3=B6nig?=
> Date: Tue, 13 May 2014 12:50:54 +0200
> Subject: [PATCH] drm/radeon: fix typo in finding PLL params
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> Otherwise the limit is raised to high.
>
> Signed-off-by: Christian K??nig
> ---
> drivers/gpu/drm/radeon/radeon_display.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_display.c
> b/drivers/gpu/drm/radeon/radeon_display.c
> index 408b6ac..f00dbbf 100644
> --- a/drivers/gpu/drm/radeon/radeon_display.c
> +++ b/drivers/gpu/drm/radeon/radeon_display.c
> @@ -999,7 +999,7 @@ void radeon_compute_pll_avivo(struct radeon_pll *pll,
>
> /* avoid high jitter with small fractional dividers */
> if (pll->flags & RADEON_PLL_USE_FRAC_FB_DIV && (fb_div % 10)) {
> - fb_div_min = max(fb_div_min, (9 - (fb_div % 10)) * 20 + 60);
> + fb_div_min = max(fb_div_min, (9 - (fb_div % 10)) * 20 + 50);
> if (fb_div < fb_div_min) {
> unsigned tmp = DIV_ROUND_UP(fb_div_min, fb_div);
> fb_div *= tmp;
> --
> 1.9.1
>
--
das eine Mal als Tragödie, dieses Mal als Farce
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: More breakage on HD7480D [ Aruba ]
On Mon, May 12, 2014 at 01:34:06AM +0100, Ken Moffat wrote: /me swears at myself for failing to copy to lkml. > Hi Christian, Alex - > > my A4 Trinity (Radeon HD7480D) was working fine by -rc3. But now > that I've tested it in -rc5 it is again broken (the screen goes > blank when KMS starts). Bisection blames: > > 3b333c55485fef0089ae7398906599d000df195e is the first bad commit > commit 3b333c55485fef0089ae7398906599d000df195e > Author: Christian König > Date: Thu Apr 24 18:39:59 2014 +0200 > > drm/radeon: avoid high jitter with small frac divs > > Signed-off-by: Christian König > > Reverting that from current HEAD [ > > commit 7e338c9991ecee9c2ac7a4cee2c2e11ecb563d02 > Merge: 9cf22e80df77 aa07c713ecfc > Author: Linus Torvalds > Date: Sun May 11 18:06:13 2014 +0900 > > Merge branch 'for-3.15' of git://linux-nfs.org/~bfields/linux > > Pull nfsd fixes from Bruce Fields. > > ] > makes it again boot. > > Note to Alex - 3.15 has been an "interesting" cycle - you fixed my > earlier problem, despite my non-response, and thanks again for that. > After that, my other radeon broke after -rc2 (I retested it after > rc4 and found that although rc4 was broken, HEAD was fixed, so > thanks also for that. Then I retested this one for -rc5. It seems > that my boxes always break when I don't have time to test new > releases :-( > > ĸen > -- > das eine Mal als Tragödie, dieses Mal als Farce -- das eine Mal als Tragödie, dieses Mal als Farce -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: relative objtree change broke tar builds?
On Wed, Jun 18, 2014 at 09:47:28PM +0200, Michal Marek wrote:
>
> The idea is that one should be able to compare as much as possible
> between the build of /usr/src/linux- built in
> /usr/src/linux-/build and /usr/src/linux- built in
> /usr/src/linux-/build.
Michal,
Now that you have sent a pull request to Linus, and therefore
addressed the main problem, may I dare to question your example ?
I only started building kernels in (approximately) spring 2000, so I
am sure that I am missing a lot of history. But /usr/src/linux*
smells of "tradition" in the Scots sense of "whit ma faither telt me
that his faither telt him" ("what my father told me that his father
told him" in english). I am sure that /usr/src/linux might have been
an expectation in the distant past, but it tends to bring along the
assumption that kernels are _built_ by that dangerous guy called
'root'.
Some of us (me included) often build things as root, but it has
many risks and people ought not to be led to believe it is
necessarily the correct way to do things. Over the past 14 years I
have built kernels in ~/ as well as in other user-writable
directories and I am puzzled about why the idea of /usr/src/linux*
continues to exist.
ĸen
--
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
rtl_nic firmware error in 3.16
Hi, I'm getting 15 lines of the following in -rc2 /bin/sh: firmware/rtl_nic/rtl8168e-3.fw.gen.S: No such file or directory followed by firmware/Makefile:185: recipe for target 'firmware/rtl_nic/rtl8168e-3.fw.gen.S' failed make[1]: *** [firmware/rtl_nic/rtl8168e-3.fw.gen.S] Error 1 I've now tried bisecting this twice, from v3.15 to v3.16-rc2 but each time the only bad version was v3.16-rc2 itself which is clearly not true. The relevant part of my .config is probably in here: # # Generic Driver Options # CONFIG_UEVENT_HELPER=y CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug" CONFIG_DEVTMPFS=y CONFIG_DEVTMPFS_MOUNT=y # CONFIG_STANDALONE is not set CONFIG_PREVENT_FIRMWARE_BUILD=y CONFIG_FW_LOADER=y # CONFIG_FIRMWARE_IN_KERNEL is not set CONFIG_EXTRA_FIRMWARE="radeon/R600_rlc.bin radeon/RS780_pfp.bin radeon/RS780_me.bin rtl_nic/rtl8168e-3.fw" CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware" CONFIG_FW_LOADER_USER_HELPER=y # CONFIG_DEBUG_DRIVER is not set # CONFIG_DEBUG_DEVRES is not set # CONFIG_SYS_HYPERVISOR is not set # CONFIG_GENERIC_CPU_DEVICES is not set CONFIG_GENERIC_CPU_AUTOPROBE=y CONFIG_DMA_SHARED_BUFFER=y and the external firmware is in /lib/firmware : ken@ac4tv ~ $ls -l /lib/firmware/rtl_nic/ total 4 -rw-r--r-- 1 root root 2804 Feb 18 18:03 rtl8168e-3.fw So I assume something is erroneously trying to recreate it. For the second run, I tried using 'make clean' on each build, and then after a while I changed to 'make mrproper'. Perhaps I should have used 'mrproper' from the start (never needed it before, and it does normally slow things down when you approach the guilty commit). I have now pulled the -rc1 tarball and confirmed that the problem is present there, but this is doing my head in, so I thought I would ask if anyone else is hitting this ? ĸen -- Nanny Ogg usually went to bed early. After all, she was an old lady. Sometimes she went to bed as early as 6 a.m. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: rtl_nic firmware error in 3.16
On Thu, Jun 26, 2014 at 03:17:23AM +0100, Ken Moffat wrote: > Hi, > > I'm getting 15 lines of the following in -rc2 > > /bin/sh: firmware/rtl_nic/rtl8168e-3.fw.gen.S: No such file or directory > > followed by > firmware/Makefile:185: recipe for target > 'firmware/rtl_nic/rtl8168e-3.fw.gen.S' failed > make[1]: *** [firmware/rtl_nic/rtl8168e-3.fw.gen.S] Error 1 > > I've now tried bisecting this twice, from v3.15 to v3.16-rc2 but > each time the only bad version was v3.16-rc2 itself which is clearly > not true. > > The relevant part of my .config is probably in here: > > # > # Generic Driver Options > # > CONFIG_UEVENT_HELPER=y > CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug" > CONFIG_DEVTMPFS=y > CONFIG_DEVTMPFS_MOUNT=y > # CONFIG_STANDALONE is not set > CONFIG_PREVENT_FIRMWARE_BUILD=y > CONFIG_FW_LOADER=y > # CONFIG_FIRMWARE_IN_KERNEL is not set > CONFIG_EXTRA_FIRMWARE="radeon/R600_rlc.bin radeon/RS780_pfp.bin > radeon/RS780_me.bin rtl_nic/rtl8168e-3.fw" > CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware" > CONFIG_FW_LOADER_USER_HELPER=y > # CONFIG_DEBUG_DRIVER is not set > # CONFIG_DEBUG_DEVRES is not set > # CONFIG_SYS_HYPERVISOR is not set > # CONFIG_GENERIC_CPU_DEVICES is not set > CONFIG_GENERIC_CPU_AUTOPROBE=y > CONFIG_DMA_SHARED_BUFFER=y > > and the external firmware is in /lib/firmware : > > ken@ac4tv ~ $ls -l /lib/firmware/rtl_nic/ > total 4 > -rw-r--r-- 1 root root 2804 Feb 18 18:03 rtl8168e-3.fw > > So I assume something is erroneously trying to recreate it. > > For the second run, I tried using 'make clean' on each build, and > then after a while I changed to 'make mrproper'. Perhaps I should > have used 'mrproper' from the start (never needed it before, and it > does normally slow things down when you approach the guilty commit). > > I have now pulled the -rc1 tarball and confirmed that the problem > is present there, but this is doing my head in, so I thought I would > ask if anyone else is hitting this ? > > ĸen Update, just in case anybody cares. I still saw it on -rc3, an attempt to build using what was in linus' tree the last time I pulled it (a bit after rc2) showed it once, and bisecting between 3.15-rc8 and 3.16-rc1 with 'make mrproper' on each build again blamed the version I labelled as bad, i.e. -rc1. So, I dropped it from my config for -rc3 to see if it would boot without this. It does, and shows no sign of wanting the firmware. Weird. I'm _fairly_ sure that an older kernel (some time after I first put this box together) complained that this firmware was missing (but appeared to still work), which is why I first added it. But since -rc3 is happy without this firmware, I don't have a problem. ĸen -- Nanny Ogg usually went to bed early. After all, she was an old lady. Sometimes she went to bed as early as 6 a.m. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: CONFIG_UEVENT_HELPER default
On Tue, Jun 24, 2014 at 11:35:09PM +0100, Ken Moffat wrote: > On Tue, Jun 24, 2014 at 12:55:26PM -0700, Andy Lutomirski wrote: > > On 06/24/2014 11:33 AM, Greg KH wrote: > > > On Tue, Jun 24, 2014 at 11:30:05AM -0700, Michael Marineau wrote: > > >> On Jun 24, 2014 11:23 AM, "Alan Stern" wrote: > > >>> [ snipping most of this ] > (i.) I got the option with 'make oldconfig' and, after reading the > help, made a decision. But, in the absence of other problems, and > if the help text is correct, it looks as if a kernel built after > accepting the default 'Y' here with recent userspace might grind to > a halt after "successfully" booting? That sounds slightly better > than "fails to boot", but only slightly. Maybe the problem needs > a lot of modules, or is it something like "it will hang for a minute, > then boot" ? > > (ii.) I understand that people continue to use ancient userspace, > and for that the 'Y' option is needed. Using ancient userspace is > a worthwhile thing for _somebody_ to try. But where is the line > between "you need to enable this" and "enabling this might be a > really bad idea" ? Maybe a specific version of udev ? > Now that I have managed to boot -rc3, with the default 'Y' on a recent system (linuxfromscratch from May), it appears to work fine. So, the text implies that bad things might happen, but so far I have not seen them. I'll stop caring. ĸen -- Nanny Ogg usually went to bed early. After all, she was an old lady. Sometimes she went to bed as early as 6 a.m. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
3.15.0-rc2 radeon HD 7480D [Aruba] blank display
I've just built 3.15.0-rc2 on this box, and discovered that I get a blank screen. The boot appears to complete (it sends me information from SMART which is from my last bootscript), and it responds to MagicSysRQ to reboot. I tried to login and run startx, but that didn't seem to make any difference - possibly something went wrong, it wasn't in my history when I booted a good kernel. This machine uses a regular old VGA cable to connect it, the following lines in dmesg make me think it has chosen the wrong connector: Apr 21 19:32:45 bluesbreaker kernel: [1.273246] [drm:radeon_dp_link_train_cr] *ERROR* displayport link status failed Apr 21 19:32:45 bluesbreaker kernel: [1.273247] [drm:radeon_dp_link_train_cr] *ERROR* clock recovery failed Apr 21 19:32:45 bluesbreaker kernel: [1.295116] Console: switching to colour frame buffer device 85x34 On a boot with 3.14.0 and earlier I get a different console size - Apr 21 20:42:44 bluesbreaker kernel: [1.445992] Console: switching to colour frame buffer device 133x54 My console font is 12x22, and my screen is 1600x1200 but it looks as if 3.15-rc2 has fallen back to trying to use 1024x768. I'm attaching what look like the relevant parts of the messages from the system logs for 3.15-rc2 and 3.14.0. Any ideas, please ? This is an AMD A4-5300 APU and not the world's fastest machine for bisecting :-( ĸen -- das eine Mal als Tragödie, dieses Mal als Farce Apr 21 20:56:19 bluesbreaker kernel: [0.766847] [drm] Initialized drm 1.1.0 20060810 Apr 21 20:56:19 bluesbreaker kernel: [0.766901] [drm] radeon kernel modesetting enabled. Apr 21 20:56:19 bluesbreaker kernel: [0.767261] [drm] initializing kernel modesetting (ARUBA 0x1002:0x9993 0x1002:0x9993). Apr 21 20:56:19 bluesbreaker kernel: [0.767324] [drm] register mmio base: 0xFEF0 Apr 21 20:56:19 bluesbreaker kernel: [0.767357] [drm] register mmio size: 262144 Apr 21 20:56:19 bluesbreaker kernel: [0.767441] ATOM BIOS: 113 Apr 21 20:56:19 bluesbreaker kernel: [0.767558] radeon :00:01.0: VRAM: 512M 0x - 0x1FFF (512M used) Apr 21 20:56:19 bluesbreaker kernel: [0.767596] radeon :00:01.0: GTT: 1024M 0x2000 - 0x5FFF Apr 21 20:56:19 bluesbreaker kernel: [0.767633] [drm] Detected VRAM RAM=512M, BAR=256M Apr 21 20:56:19 bluesbreaker kernel: [0.768866] [drm] RAM width 64bits DDR Apr 21 20:56:19 bluesbreaker kernel: [0.768943] [TTM] Zone kernel: Available graphics memory: 1708830 kiB Apr 21 20:56:19 bluesbreaker kernel: [0.768976] [TTM] Initializing pool allocator Apr 21 20:56:19 bluesbreaker kernel: [0.769013] [TTM] Initializing DMA pool allocator Apr 21 20:56:19 bluesbreaker kernel: [0.769061] [drm] radeon: 512M of VRAM memory ready Apr 21 20:56:19 bluesbreaker kernel: [0.769094] [drm] radeon: 1024M of GTT memory ready. Apr 21 20:56:19 bluesbreaker kernel: [0.769140] [drm] Loading ARUBA Microcode Apr 21 20:56:19 bluesbreaker kernel: [0.769173] [drm] Internal thermal controller without fan control Apr 21 20:56:19 bluesbreaker kernel: [0.769407] [drm] radeon: dpm initialized Apr 21 20:56:19 bluesbreaker kernel: [0.769611] [drm] GART: num cpu pages 262144, num gpu pages 262144 Apr 21 20:56:19 bluesbreaker kernel: [0.779832] [drm] PCIE GART of 1024M enabled (table at 0x00276000). Apr 21 20:56:19 bluesbreaker kernel: [0.779985] radeon :00:01.0: WB enabled Apr 21 20:56:19 bluesbreaker kernel: [0.780020] radeon :00:01.0: fence driver on ring 0 use gpu addr 0x2c00 and cpu addr 0x8800994f7c00 Apr 21 20:56:19 bluesbreaker kernel: [0.780787] radeon :00:01.0: fence driver on ring 5 use gpu addr 0x00075a18 and cpu addr 0xc90010235a18 Apr 21 20:56:19 bluesbreaker kernel: [0.780826] radeon :00:01.0: fence driver on ring 1 use gpu addr 0x2c04 and cpu addr 0x8800994f7c04 Apr 21 20:56:19 bluesbreaker kernel: [0.780864] radeon :00:01.0: fence driver on ring 2 use gpu addr 0x2c08 and cpu addr 0x8800994f7c08 Apr 21 20:56:19 bluesbreaker kernel: [0.780902] radeon :00:01.0: fence driver on ring 3 use gpu addr 0x2c0c and cpu addr 0x8800994f7c0c Apr 21 20:56:19 bluesbreaker kernel: [0.780941] radeon :00:01.0: fence driver on ring 4 use gpu addr 0x2c10 and cpu addr 0x8800994f7c10 Apr 21 20:56:19 bluesbreaker kernel: [0.780980] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). Apr 21 20:56:19 bluesbreaker kernel: [0.781013] [drm] Driver supports precise vblank timestamp query. Apr 21 20:56:19 bluesbreaker kernel: [0.781061] radeon :00:01.0: irq 41 for MSI/MSI-X Apr 21 20:56:19 bluesbreaker kernel: [0.781072] radeon :00:01.0: radeon: using MSI. Apr 21 20:56:19 bluesbreaker kernel: [0.781374] [drm] radeon: irq initialized. Apr 21 20:56:19 bluesbreaker kernel: [0.800502
Re: 3.15.0-rc2 radeon HD 7480D [Aruba] blank display
On Mon, Apr 21, 2014 at 04:54:15PM -0400, Alex Deucher wrote: > On Mon, Apr 21, 2014 at 4:32 PM, Ken Moffat wrote: > > I've just built 3.15.0-rc2 on this box, and discovered that I get a > > blank screen. The boot appears to complete (it sends me information > > from SMART which is from my last bootscript), and it responds to > > MagicSysRQ to reboot. I tried to login and run startx, but that > > didn't seem to make any difference - possibly something went wrong, > > it wasn't in my history when I booted a good kernel. > > > > This machine uses a regular old VGA cable to connect it, the > > following lines in dmesg make me think it has chosen the wrong > > connector: > > VGA is implemented as a DP to VGA bridge on APUs. > > > > > Apr 21 19:32:45 bluesbreaker kernel: [1.273246] > > [drm:radeon_dp_link_train_cr] *ERROR* displayport link status failed > > Apr 21 19:32:45 bluesbreaker kernel: [1.273247] > > [drm:radeon_dp_link_train_cr] *ERROR* clock recovery failed > > Apr 21 19:32:45 bluesbreaker kernel: [1.295116] Console: > > switching to colour frame buffer device 85x34 > > > > On a boot with 3.14.0 and earlier I get a different console size - > > Apr 21 20:42:44 bluesbreaker kernel: [1.445992] Console: > > switching to colour frame buffer device 133x54 > > > > My console font is 12x22, and my screen is 1600x1200 but it looks > > as if 3.15-rc2 has fallen back to trying to use 1024x768. > > > > I'm attaching what look like the relevant parts of the messages > > from the system logs for 3.15-rc2 and 3.14.0. > > > > Any ideas, please ? This is an AMD A4-5300 APU and not the world's > > fastest machine for bisecting :-( > > I'd guess it's either the pll rework patches or the switch to the > common dp helper code patches. It would be helpful if you could > bisect. > > Alex OK, I guess I can do the builds on a faster machine. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.15.0-rc2 radeon HD 7480D [Aruba] blank display
On Tue, Apr 22, 2014 at 03:31:06AM +0100, Ken Moffat wrote: [ resending, somehow lkml dropped out of the Cc. ] > On Tue, Apr 22, 2014 at 12:19:40AM +0100, Ken Moffat wrote: > > On Mon, Apr 21, 2014 at 05:29:27PM -0400, Ed Tomlinson wrote: > > > > Ken, > > > > > > You might want to try reverting: > > > > > > commit 379dfc25e257ffe10eb53b86d2375f7c0f4f33ef > > > Author: Alex Deucher > > > Date: Mon Apr 7 10:33:46 2014 -0400 > > > > > > drm/radeon/dp: switch to the common i2c over aux code > > > > > > Provides a nice cleanup in radeon. > > > > > > Signed-off-by: Alex Deucher > > > Signed-off-by: Christian König > > > > > > This fixed a similar problem here (see the drm pull thread for rc1) > > > > > > Thanks > > > Ed Tomlinson > > > > Tried reverting that from rc2, but it didn't help. Thanks anyway. > > > > Well, I *believed* I had created a patch for that commit, and > reverted it from -rc2 with patch -R. But I've now bisected through > drivers/gpu/drm between v3.14.0 and v3.15-rc2 and the bisection > pointed to that same commit, so I guess I did something wrong. > > There were a couple of other issues along the way (mounting nfs > hung on one commit, startx hung on several of the commits, but I've > marked those as "good" because I had a display, even if the system > was not usable). > > I've now gone back to linus' tree that I cloned a few hours ago, > i.e. > commit c089b229dfdd09d59a11d8bc2344bf8196d575ce > Merge: 9ac03675010a 0565103d1adb > Author: Linus Torvalds > Date: Mon Apr 21 10:05:35 2014 -0700 > > Merge branch 'for-linus' of > git://git.kernel.org/pub/scm/linux/kernel/git/rw/uml > > created a branch, and *definitely* reverted > 379dfc25e257ffe10eb53b86d2375f7c0f4f33ef (using git revert) in that > branch. And this version works fine. > > So belatedly I see that I seem to have the same problem as Ed. Or > at least that the same commit is causing both our problems. > > Alex - do you need any more information from me to help with this ? > > ĸen > -- > das eine Mal als Tragödie, dieses Mal als Farce -- das eine Mal als Tragödie, dieses Mal als Farce -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Resume from suspend broken in 3.15. (bisected)
Hi Daniel,
I've only started full testing of 3.15 on one of my machines now
that -rc7 has been released (this one had two issues in the radeon
code, second was fixed in rc7). Unfortunately, suspend to RAM
(pm-suspend), or rather the wake-up, is broken on this box [ my
other two boxes are fine in rc7 ].
Bisection identified one of your commits -
commit 25f397a429dfa43f22c278d0119a60a343aa568f
Author: Daniel Vetter
Date: Fri Jul 19 18:57:11 2013 +0200
drm/crtc-helper: explicit DPMS on after modeset
Atm the crtc helper implementation of set_config has really
inconsisten semantics: If just an fb update is good enough, dpms state
will be left as-is, but if we do a full modeset we force everything to
dpms on.
This change has already been applied to the i915 modeset code in
('git show' stops at that point)
I have attempted to revert this commit from Linus' current tree,
but git considered that there was a conflict, and I did not know how
to address it, so I aborted. The conflict is :
<<< HEAD
if (connector->dpms != DRM_MODE_DPMS_ON) {
DRM_DEBUG_KMS("connector dpms not on,
full mode switch\n");
mode_changed = true;
}
===
>>> parent of 25f397a429df... drm/crtc-helper: explicit DPMS on
>>> after modeset
break;
}
}
The processor is an AMD A4 APU. The symptoms after this commit are
that pm-suspend works (I invoke it from my keyboard's sleep key),
i.e. the power LED on the case goes out and the monitor goes black
and reports no signal. When I press a key to resume, the power LED
comes on but the screen stays black. Magic-SysRQ does not work and
I have to use the case switch to reboot. That results in filesystem
errors which fsck fixes and warns about (probably, just a sign of
unclean shutdown).
The only thing in the log are a couple of messages from EXT4 at the
end of putting the box to sleep -
May 28 16:19:02 bluesbreaker kernel: [ 39.440859] EXT4-fs (sda10):
re-mounted. Opts: commit=0
May 28 16:19:02 bluesbreaker kernel: [ 39.592318] EXT4-fs (sda13):
re-mounted. Opts: commit=0
May 28 16:20:05 bluesbreaker syslogd 1.5.0: restart.
What can I do to help debug this ?
ĸen
--
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Resume from suspend broken in 3.15. (bisected)
On Wed, May 28, 2014 at 06:25:21PM +0100, Ken Moffat wrote:
> Hi Daniel,
>
[ correcting details, confirming that reverting this does fix the
problem, adding Cc:s ]
> I've only started full testing of 3.15 on one of my machines now
> that -rc7 has been released (this one had two issues in the radeon
> code, second was fixed in rc7). Unfortunately, suspend to RAM
> (pm-suspend), or rather the wake-up, is broken on this box [ my
> other two boxes are fine in rc7 ].
>
> Bisection identified one of your commits -
>
> commit 25f397a429dfa43f22c278d0119a60a343aa568f
> Author: Daniel Vetter
> Date: Fri Jul 19 18:57:11 2013 +0200
>
> drm/crtc-helper: explicit DPMS on after modeset
>
> Atm the crtc helper implementation of set_config has really
> inconsisten semantics: If just an fb update is good enough, dpms state
> will be left as-is, but if we do a full modeset we force everything to
> dpms on.
>
> This change has already been applied to the i915 modeset code in
>
> ('git show' stops at that point)
update : I've no idea what was going on there, nor for the problem
with attempting to revert it. I've now gone back into git,
extracted the full commit to a file with 'git show', and then used
git apply -R to revert it from 3.15-rc7. That version wakes up from
suspend to RAM, 3.15-rc7 itself did not.
Maybe I was still in git log when I thought I was on the command
line. Anyway, snipping git's view of my failed attempt to revert
it, and adding Dan and Alex who were CC'd on the commit.
>
> The processor is an AMD A4 APU. The symptoms after this commit are
> that pm-suspend works (I invoke it from my keyboard's sleep key),
> i.e. the power LED on the case goes out and the monitor goes black
> and reports no signal. When I press a key to resume, the power LED
> comes on but the screen stays black. Magic-SysRQ does not work and
> I have to use the case switch to reboot. That results in filesystem
> errors which fsck fixes and warns about (probably, just a sign of
> unclean shutdown).
>
> The only thing in the log are a couple of messages from EXT4 at the
> end of putting the box to sleep -
> May 28 16:19:02 bluesbreaker kernel: [ 39.440859] EXT4-fs (sda10):
> re-mounted. Opts: commit=0
> May 28 16:19:02 bluesbreaker kernel: [ 39.592318] EXT4-fs (sda13):
> re-mounted. Opts: commit=0
> May 28 16:20:05 bluesbreaker syslogd 1.5.0: restart.
>
> What can I do to help debug this ?
>
ĸen
--
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Resume from suspend broken in 3.15. (bisected)
On Thu, May 29, 2014 at 10:57:20PM +0200, Daniel Vetter wrote:
> On Thu, May 29, 2014 at 10:47 PM, Alex Deucher wrote:
> > On Thu, May 29, 2014 at 2:03 AM, Dan Carpenter
> > wrote:
> >> On Wed, May 28, 2014 at 08:26:53PM -0400, Alex Deucher wrote:
> >>> On Wed, May 28, 2014 at 7:49 PM, Ken Moffat
> >>> wrote:
> >>> > On Wed, May 28, 2014 at 06:25:21PM +0100, Ken Moffat wrote:
> >>> >> Hi Daniel,
> >>> >>
> >>> >
> >>> > [ correcting details, confirming that reverting this does fix the
> >>> > problem, adding Cc:s ]
> >>> >
> >>> >> I've only started full testing of 3.15 on one of my machines now
> >>> >> that -rc7 has been released (this one had two issues in the radeon
> >>> >> code, second was fixed in rc7). Unfortunately, suspend to RAM
> >>> >> (pm-suspend), or rather the wake-up, is broken on this box [ my
> >>> >> other two boxes are fine in rc7 ].
> >>> >>
> >>> >> Bisection identified one of your commits -
> >>> >>
> >>> >> commit 25f397a429dfa43f22c278d0119a60a343aa568f
> >>> >> Author: Daniel Vetter
> >>> >> Date: Fri Jul 19 18:57:11 2013 +0200
> >>> >>
> >>> >> drm/crtc-helper: explicit DPMS on after modeset
> >>> >>
> >>> >> Atm the crtc helper implementation of set_config has really
> >>> >> inconsisten semantics: If just an fb update is good enough, dpms
> >>> >> state
> >>> >> will be left as-is, but if we do a full modeset we force
> >>> >> everything to
> >>> >> dpms on.
> >>> >>
> >>> >> This change has already been applied to the i915 modeset code in
> >>> >>
> >>> >> ('git show' stops at that point)
> >>> >
> >>> > update : I've no idea what was going on there, nor for the problem
> >>> > with attempting to revert it. I've now gone back into git,
> >>> > extracted the full commit to a file with 'git show', and then used
> >>> > git apply -R to revert it from 3.15-rc7. That version wakes up from
> >>> > suspend to RAM, 3.15-rc7 itself did not.
> >>> >
> >>> > Maybe I was still in git log when I thought I was on the command
> >>> > line. Anyway, snipping git's view of my failed attempt to revert
> >>> > it, and adding Dan and Alex who were CC'd on the commit.
> >>> >
> >>>
> >>> Duplicate of:
> >>> https://bugzilla.kernel.org/show_bug.cgi?id=74751
> >>> and also reported here:
> >>> https://lkml.org/lkml/2014/5/2/388
> >>> Unless there is a good reason to keep the commit, I'd say let's just
> >>> revert it.
> >>>
> >>
> >> Yes. Let's revert it.
> >
> > The actual bad commit is 177cf92de4aa97ec1435987e91696ed8b5023130, but
> > for some reason git bisect always comes up with
> > 25f397a429dfa43f22c278d0119a60a343aa568f which has been in the tree
> > for almost a year now. I don't know why.
>
> Quick patch which is worth a shot before we revert 177cf.
> -Daniel
>
> diff --git a/drivers/gpu/drm/radeon/radeon_device.c
> b/drivers/gpu/drm/radeon/radeon_device.c
> index c2edb2d14030..cf5d299cc623 100644
> --- a/drivers/gpu/drm/radeon/radeon_device.c
> +++ b/drivers/gpu/drm/radeon/radeon_device.c
> @@ -1534,11 +1534,6 @@ int radeon_resume_kms(struct drm_device *dev, bool
> resume, bool fbcon)
>
> radeon_restore_bios_scratch_regs(rdev);
>
> - if (fbcon) {
> - radeon_fbdev_set_suspend(rdev, 0);
> - console_unlock();
> - }
> -
> /* init dig PHYs, disp eng pll */
> if (rdev->is_atom_bios) {
> radeon_atom_encoder_init(rdev);
> @@ -1563,6 +1558,12 @@ int radeon_resume_kms(struct drm_device *dev, bool
> resume, bool fbcon)
> }
>
> drm_kms_helper_poll_enable(dev);
> +
> + if (fbcon) {
> + radeon_fbdev_set_suspend(rdev, 0);
> + console_unlock();
> + }
> +
> return 0;
> }
>
Thanks, Daniel.
That works for me (with -rc7) on my A4 Trinity (Radeon HD7480D). I
also tested it on my other radeon (RS780L - Radeon 3000) and saw no
problems in suspend-resume. If useful, you can add my tested-by.
ĸen
--
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Licensing & copyright of kernel .config files (defconfig, *config)
On Sun, Jun 01, 2014 at 01:43:01AM +, Robin H. Johnson wrote: > (Please CC me on replies, not subscribed to LKML) > > Hi, > > Somewhat of an odd question, but none of the files in question seem to > have a copyright header on them... > > For a kernel .config file, either from one of the defconfig or any other > *config option that automates the answer: > 1. What license does the file fall under? > 2. Who are the copyright holders? > > Naively, since the defconfigs are bundled with the kernel, that could > fall under GPLv2-only implicitly, but lacking any explicit copyright > headers makes this interesting (arch/*/configs/* contain lots of files, > no copyright headers on them). > I am not a lawyer, but surely _many_ of the kernel files do not contain any explicit copyright information ? > If I manually write the names of some configuration options to a new > .config file, at that point I logically am the only author and have > copyright of it. My editor slaps a default license on it of BSD-2. > Thereafter I run olddefconfig, and now it's a combined work of the > kernel's defconfig and my manual settings. If GPL-2 was inherited from > the kernel tree, this is now a combined BSD-GPL2 work, or is it? The > kernel config tools did consider my file as input, possibly overrode the > settings if they didn't work with others, and re-output everything. > Why does your editor put a default license on anything ? In some cases, it is bound to be wrong. For example, if you were to ever submit a kernel patch, in the kernel the license would be GPL-2 although, if you created a new file, you could also license that as BSD-2 if it was not a derivative of existing kernel code. Similarly, if you ever create a patch for any other project which does not use a BSD license, then your patch will have uncertain status. If I was being awkward, I would suggest that the config would not be useful until you had run it through "make oldconfig" or similar, and that therefore the kernel license of GPL-2 applies. > If the files are to be marked with a copyright header, who is the holder > of it that it should be attributed to? > Iff the work is copyrightable (I do not have an opinion on that), surely the license only matters if you breach it ? ;-) If you distribute a compiled kernel with the source, and all of that source is GPL-2, then I assume you are in the clear. For "extras" which include binaries without source, my understanding is that you would always be vulnerable to kernel copyright holders. So, I suspect that the attribution of a config file is not particularly important. > Alternatively, is this a case where the work is not copyrightable, and > the files should have a notice to that effect? > > Background: > Gentoo has a bunch of "stock" kernel configurations for release > engineering, our initramfs tool (genkernel), and other endeavors over > the years. These projects claim BSD, GPL2, LGPL2 on various pieces, and > I don't think they can all be correct. I'm working on getting them into > one place, because some of them have been getting stale, but the > differing licenses raised a red flag to me. > To the extent that GPL-2 can include LGPL-2 and BSD, I suggest that you label them all as GPL-2. That is the licence of the kernel, and for practical reasons it will not change (this was discussed when somebody asked about GPL-3 : even if the main copyright holders wanted to make the change (and many do not), some copyright holders are no longer contactable). You might be able to dual-license some of these distro files, but I have no idea if that would be appropriate. ĸen -- Nanny Ogg usually went to bed early. After all, she was an old lady. Sometimes she went to bed as early as 6 a.m. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC 1/2] MAINTAINERS: Add "R:" designated-reviewers tag
On Mon, Jun 02, 2014 at 05:12:05PM -0700, Joe Perches wrote: > > "Tested-by:" tags would be more helpful if the test > cases that were used were somehow sent along with the > signature. > To me, that seems either a perverse, or else a bureaucratic, interpretation of what should go where. Tested-by is usually used for a fix of some problem, often a regression. A good commit message will explain the problem. I have recently offered this tag in two cases - in the first case it did not boot without the fix, in the second it did not wake up from suspend. In each case, only one of my boxes was affected. Do you think I should have insisted that some of my lspci -V information was appended to the commit (they both affected the radeon code) if my tag was going to be added ? This is _often_ not like userspace programs where you can write a testsuite to exercise the corner cases. Kernel problems can be tied up with intricate details of the hardware, or equally they might happen only for certain usage, and for those it might not be at all obvious what is "special" about the affected usage. ĸen -- Nanny Ogg usually went to bed early. After all, she was an old lady. Sometimes she went to bed as early as 6 a.m. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: CONFIG_UEVENT_HELPER default
On Tue, Jun 24, 2014 at 12:55:26PM -0700, Andy Lutomirski wrote: > On 06/24/2014 11:33 AM, Greg KH wrote: > > On Tue, Jun 24, 2014 at 11:30:05AM -0700, Michael Marineau wrote: > >> On Jun 24, 2014 11:23 AM, "Alan Stern" wrote: > >>> > >>> Michael and Greg: > >>> > >>> The help text for CONFIG_UEVENT_HELPER says (among other things): > >>> > >>> This should not be used today, because usual systems create > >>> many events at bootup or device discovery in a very short time > >>> frame. > >>> > >>> If it shouldn't be used, why does it default to 'y'? > >>> > >>> Alan Stern > >>> > >> > >> To introduce the option but not change the default behavior. (yet?) I don't > >> really have an opinion one way or the other, I just defaulted to being > >> conservative. > > > > Yes, being conservative is good as turning this off with older systems > > (like the pathological Fedora 3 system that some kernel developers still > > use for testing), would result in a non-booting box. So if you know > > that your system is "new enough", it's safe to turn off, but if you have > > a doubt, leave it on to be safe. > > As far as I know, there's no real requirement that a defconfig kernel be > able to boot old userspace. We want an oldconfig kernel to be able to > boot old userspace, but changing the default won't affect that. > > For example, a defconfig kernel won't boot opensuse 9. > > --Andy I noticed this help message yesterday, and decided that I almost-certainly did NOT want it (that system is about 6 weeks old, with then-current releases of everything). But I was not able to complete the kernel build because of other problems (possibly related to gcc-4.9.1) and I have other things to do at the moment. All of which means that I can not, for the moment, review what will happen if I let this option get enabled. Two things about this default concern me: (i.) I got the option with 'make oldconfig' and, after reading the help, made a decision. But, in the absence of other problems, and if the help text is correct, it looks as if a kernel built after accepting the default 'Y' here with recent userspace might grind to a halt after "successfully" booting? That sounds slightly better than "fails to boot", but only slightly. Maybe the problem needs a lot of modules, or is it something like "it will hang for a minute, then boot" ? (ii.) I understand that people continue to use ancient userspace, and for that the 'Y' option is needed. Using ancient userspace is a worthwhile thing for _somebody_ to try. But where is the line between "you need to enable this" and "enabling this might be a really bad idea" ? Maybe a specific version of udev ? ĸen -- Nanny Ogg usually went to bed early. After all, she was an old lady. Sometimes she went to bed as early as 6 a.m. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 24/28] Remove DEPRECATED
On Sun, Feb 09, 2014 at 06:05:41PM -0500, Gene Heskett wrote: > On Sunday 09 February 2014, Paul Bolle wrote: > > > >Feel free to open a new thread, with the relevant details, and involve > >the relevant people and lists. I have no idea what you're going on about > >and could not care less (in the context of this thread). > > > > > >Paul Bolle > > Been tried, got zero response. Frankly, posting just to lkml, hoping the > revalent people see it, is beginning to act like posting to a black hole. > I saw one response to you, from Randy Dunlap, asking for more information : https://lkml.org/lkml/2014/2/8/153 After your posts a few days ago, I'm tempted to suggest you check your spam filters, and also any mail files your virus scanner might have quarantined. But it is also possible that you just haven't received it - email is like that. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AMD microcode fails to update with v3.8.3 and newer, bisect failed
On Wed, Jan 01, 2014 at 09:25:55PM -0500, Gene Heskett wrote: > On Wednesday 01 January 2014, Jason Cooper wrote: > > > >Are the rootfs binaries 32 bit? If so, did you enable > >CONFIG_IA32_EMULATION? > > That line above does not now exist in my .config for 3.8.2. Ditto for > the .config in 3.12.6. > > How is the best way to restore this? > but Jason also wrote: > >You may be able to bypass your PAE problem by running a 64bit kernel > >with the above option. Although, I'd prefer to get to the bottom of the > >failure. :) > > Gene - If I've understood you correctly, you are now running a 32-bit kernel - or perhaps 32-bit with PAE. The CONFIG_IA32_EMULATION option is for a 64-bit [ x86_64 ] kernel, to enable it to run 32-bit userspace (either only 32bit userspace, or multilib). So, it is irrelevant for a 32-bit kernel - those can only run 32-bit userspace. If your previous "good" kernel was either 32-bit or 32-bit with PAE, you might need to change a lot of .config settings to get a reliably working 64-bit kernel. And vice-versa for a well-adapted 32-bit kernel if you had previously been running 64-bit. Your main problem appears to be that part of kde is unusable, and you attribute this to the old firmware. That may well be true (I don't use kde), but I will be very surprised if that is the _expected_ result of running the old firmware on an early phenom. Usually, running old firmware doesn't seem to make a lot of difference, except in obscure corner cases. I will note that my own phenom *sometimes* seems to lose its lunch when running make -j4, and in those cases dropping the caches and running a less-adventurous parallel make [ -j3 or -j2 ] seems to fix it. But that doesn't seem to be analagous to the kde problem you see (and when I last looked, a few months ago, my firmware appeared to be current, so I guess mine is the common "cheap consumer hardware" sort of problem). Anyway, best of luck and I hope you get it sorted. Perhaps I should also upset you by mentioning that 3.8 seems to be out of maintenance (except, probably, from ubuntu). In general, the devs here aren't too interested in old kernels which are no longer supported. OTOH, I'm reluctant to suggest what I would normally suggest in the "distro" (LFS) I care about - i.e. try both 3.12.0 and 3.12.latest, both from a known good .config using 'make oldconfig' - because you are starting from an old version and it isn't obvious where the problem started. Those of us with specific requirements really need to keep checking each kernel release (or ideally some of the later -rc versions) to make sure that things we care about haven't been trashed. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AMD microcode fails to update with v3.8.3 and newer, bisect failed
On Thu, Jan 02, 2014 at 04:08:15AM +, Ken Moffat wrote: > > Anyway, best of luck and I hope you get it sorted. > One further suggestion, since you appear to be at the "running round in circles" stage - 1. Start with a good kernel. In this case, I suppose 3.8.2 is the right place to begin. 2. But then change the .config to - 2.1 ensure that your disk filesystems are built in - e.g. all of ext2, ext3, ext4 and anything else you know you are using. Normally, only the fs for '/' needs to be built in, but you seem to have seen other issues so I would just build in everything you need. 2.2 build in everything else you need to boot (normally, the disk controller(s) ) so that you don't need an initrd. 2.3 drop the things you don't need - this is merely to reduce the time it takes to build a kernel. Distros normally build _everything_ as a module. Provided you can boot without an initrd, reducing the number of modules only makes it quicker to build a new kernel - but if you are starting from something which looks like "allmodconfig" it can save a lot of time. 2.4 for your convenience, ensure that you have enabled the config to be stored in /proc/config.gz - once you are building your own slimmed-down kernels, you probably won't want to mess about with distro "install" scripts so just copying the bzimage to /boot/vmlinuz-x.y.z, make modules_install, and editing /boot/grub/grub.cfg (yes, really!) will save a lot of time. 2.5 Add your own version, e.g. for 3.8.2 change EXTRAVERSION to 2-A so that the kernel will be 3.8.2-A (this stops it overwriting existing existing 3.8.2 modules, in case the first attempt doesn't do what you want). 3. That might take two or three attempts to get to a good config, but after that you should be able to use the slimmer config (from zcat /proc/config.gz) to create .config for any newer version you want to test or bisect, and then just run make oldconfig before you build. Also, when you get back to bisecting, the version in the kernel Makefile might not be what you expect. If in doubt, you can change it to something which doesn't overwrite any existing modules, e.g. 3.8.bisect-1 etc. HTH ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AMD microcode fails to update with v3.8.3 and newer, bisect failed
On Thu, Jan 02, 2014 at 12:24:56AM -0500, Gene Heskett wrote:
> On Wednesday 01 January 2014, Ken Moffat wrote:
> >On Thu, Jan 02, 2014 at 04:08:15AM +0000, Ken Moffat wrote:
> >> Anyway, best of luck and I hope you get it sorted.
> >
> > One further suggestion, since you appear to be at the "running
> >round in circles" stage -
> >
> >1. Start with a good kernel. In this case, I suppose 3.8.2 is the
> >right place to begin.
>
> That has since died, won't boot, don't recall changing a thing in the
> .config either.
>
That makes things harder. Do you have any backups from when it
booted ? (kernel, modules, and grub.cfg might all have been
accidentally overwritten).
To reply to your earlier post about a lack of local tarballs : try
installing wget (if you don't already have it), or use a firefox
variant on a desktop machine and then transfer it to the phenom.
For convenience, I always download the 3.x.0 kernel as a tarball,
and then 3.x.{1..n} as patches. And I usually rename the directory
as linux-3.x-stable so that I can remember what it is, and also so
that it doesn't get overwritten if I untar a fresh copy for other
reasons. So, first I use 'head Makefile' to confirm the current
version. I then remove any stable patch using 'xzcat | patch -R
-p1' so that I'm back to 3.x.0 and then apply the patch for the next
version I want to test.
Lots of possible variations on this exist, particularly when I'm
bisecting. The important thing is to have a process which works for
you - for stable kernels, some people will prefer to use a fresh
3.x.y tarball each time.
> >2. But then change the .config to -
> >
> >2.1 ensure that your disk filesystems are built in - e.g. all of
> >ext2, ext3, ext4 and anything else you know you are using.
>
> Should I edit in the /etc/grub.d to remove the modprobe ext2, or will it
> more or less silently shake its head and go on.
>
I think the modprobe instructions in the grub files are used to
ensure that grub can load its own modules before it tries to read
the specified kernel. So no, I would not change that. The kernel's
own modules (specifically ext2/3/4) are something else - without an
initrd, the kernel needs the filesystem used for '/' to be built in.
So : if the kernel starts to boot, the grub part is ok.
> >Normally, only the fs for '/' needs to be built in, but you seem to
> >have seen other issues so I would just build in everything you need.
> >
> >2.2 build in everything else you need to boot (normally, the disk
> >controller(s) ) so that you don't need an initrd.
>
> That would be forcedeath, nouveau, v4l1 and 2 and hda_audio for starters.
>
Nouveau and forcedeath will probably be convenient, but the rest
ought to be ok as modules. In this context, I mean whatever you need
for the kernel to get to a position where it can load modules. So,
it needs the disk driver(s) and the root filesystem (where
/lib/modules lives).
> Since this kernel isn't near new enough for the config tricks mentioned,
> maybe I'll see if the linux-stable I have can do a 3.11.0 checkout.
>
> >2.4 for your convenience, ensure that you have enabled the config to
> >be stored in /proc/config.gz - once you are building your own
> >slimmed-down kernels, you probably won't want to mess about with
> >distro "install" scripts so just copying the bzimage to
> >/boot/vmlinuz-x.y.z, make modules_install, and editing
> >/boot/grub/grub.cfg (yes, really!) will save a lot of time.
>
> My present script does everything but edit grub.cfg.
>
[...]
> >3. That might take two or three attempts to get to a good config,
> >but after that you should be able to use the slimmer config (from
> >zcat /proc/config.gz) to create .config for any newer version you
> >want to test or bisect, and then just run make oldconfig before you
> >build.
> >
> > Also, when you get back to bisecting, the version in the kernel
> >Makefile might not be what you expect. If in doubt, you can change
> >it to something which doesn't overwrite any existing modules, e.g.
> >3.8.bisect-1 etc.
>
> Presently it uses a + sign for in between versions.
>
I'm more familiar with bisecting in -rc versions : for those, the
Makefile version will jump back to what it was when the code was
developed. Very confusing if you weren't expecting it.
> > HTH
>
> It will, if I don't lose my place...
> >ؤ¸en
>
> My "makeit" script does cd's here and there, so its vital that the Makefile
> version matches the makeit version. I've thought of that, and fixed it in
> the copy I use to m
Re: sock puppets (Re: (Song) ** SystemD)
On Sun, Oct 05, 2014 at 09:15:11PM +, Gregory Smith wrote: > Just because you disagree with something does not make it a troll. > Just because someone continued to post to a mailing list which he > was unrightly banned from (because systemd negativity is a no-no > for some), does not mean the message is for trolling. > > Trying to suck up or find common ground with the systemd people > will fail. > > Rambling Proposal pt 1 of 2. Unix-like Fork. "Indelible Linux/Crystalline > Linux" > youtu.be/N18rNxe3Z-o > > Rambling Proposal pt 2 of 2. Unix-like Fork. "Indelible Linux/Crystalline > Linux" > youtu.be/TG1uqwNzlnk > > > On 10/5/14, Joel Rees wrote: > > On Sun, Oct 5, 2014 at 7:54 PM, Chuck Ebbert > > wrote: > >> On Sun, 5 Oct 2014 10:29:24 + > >> Gregory Smith wrote: > >> [...] > > > > Chuck, Al, anyone else paying attention to "Gregory" or "Tom Collins" > > or whatever he's calling himself -- I'll repeat what I posted to > > debian-user, but this is quite apparently a sockpuppet, either > > engaging in recreational trolling, or trying very hard to make it > > impossible to discuss systemd with any semblance of rationally. > > Not everybody on lkml likes systemd (I certainly don't), but I think almost everyone will agree with Joel, and many will agree with Al. For those of us trying to follow what is going on _in_the_kernel_, this list is already noisy enough. My 'killfile' just gained a new entry. ĸen (hoping that somebody will go ahead with 'Boot Init Through Computer Hardware') -- Nanny Ogg usually went to bed early. After all, she was an old lady. Sometimes she went to bed as early as 6 a.m. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Lockups with 4.2-rc kernels and qemu
(Cc'ing qemu-devel, please keep me in the Cc). TL;DR - qemu locks up my machine when I use 4.2-rc kernels. I only use qemu from time to time, mostly to test changes to my own scripts, or new package versions, in beyond.linuxfromscratch.org. A few days ago I came back to that, building an LFS system from the beginning of this month and then using that to try out my changes. In the beginning I built a 4.2-rc5 kernel and booted that system in qemu-2.4.0. I had several lockups along the way from a minimal system to the end of my attempts to build a full desktop, and in fact I dropped back to a 4.1 kernel and qemu-2.3.0 before I completed the build. Mostly, the qemu system appeared to have been idle when the box locked up, or else idle apart from xscreensaver, but on one occasion it ran through several steps to build Xorg protocol header packages - I write a 'stamp' file so that I can resume after a failure, and several of these were created, but empty (instead of a small amount of version, time, space data) and it later turned out that nothing had been installed for those packages. In all cases I have nothing relevant in either the guest or the host logs. On one or two occasions I got the flashing keyboard LEDs. After the initial problems I ran memtest86+ for 10 hours without any errors. In the end, I dropped back to a 4.1 kernel and also qemu-2.3.0 because my concern was to finish the build. I was thinking - erroneously, of course - that this was a qemu problem. Gradually, I moved to 4.2-rc kernels and things appeared to be ok. But today I installed 4.2-rc8 and thought about trying to create a test-case to see if the kernel+qemu combination is probably ok. I decided to start qemu, login, run startx [ xscreensaver will be invoked, otherwise userspace is idle ], and leave it for 3 hours - lockups varied in how long they took to appear, but all were in 2 hours or less. So, I left -rc8 and qemu-2.3.0, and when I returned to it after about 3 and a quarter hours the box had locked up. The machine is an AMD phenom (not always the most reliable, I had to drop caches today to get it to reliably build -rc8 with make -j 4 but otherwise it seems to have not needed that in the past month). I'll attach the kernel config. I compiled qemu-2.3.0 with: sed -i '/resource/ i#include ' \ fsdev/virtfs-proxy-helper.c ./configure --prefix=/usr \ --sysconfdir=/etc \ --docdir=/usr/share/doc/qemu-2.3.0 \ --target-list=x86_64-softmmu \ --audio-drv-list=alsa and I use a wrapper script for qemu which tells me that what I am actually running is: qemu-system-x86_64 -enable-kvm -hda svn20150803-32-desk2.img -hdb svn-logging-tools.img -m 2G -usb -usbdevice tablet -show-cursor -display sdl -cpu kvm32 -monitor stdio -smp 4 -vga std That was for building a new system, later runs only use a -hda image. And all of the uses have been for i686 guests. The host (and the initial guest used to build the new system) is gcc-5.1.0, the newly built guests 5.2.0; binutils 2.25 / 2.25.1; glibc 2.21 throughout. Because I need to leave the system running for up to 3 hours to get an idea if a particular kernel is ok, I don't think this problem lends itself to bisection. Any suggestions, please ? ĸen -- This one goes up to eleven: but only on a clear day, with the wind in the right direction. # # Automatically generated file; DO NOT EDIT. # Linux/x86 4.2.0-rc8 Kernel Configuration # CONFIG_64BIT=y CONFIG_X86_64=y CONFIG_X86=y CONFIG_INSTRUCTION_DECODER=y CONFIG_PERF_EVENTS_INTEL_UNCORE=y CONFIG_OUTPUT_FORMAT="elf64-x86-64" CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig" CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_MMU=y CONFIG_NEED_DMA_MAP_STATE=y CONFIG_NEED_SG_DMA_LENGTH=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_ARCH_HAS_CPU_RELAX=y CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y CONFIG_ARCH_WANT_GENERAL_HUGETLB=y CONFIG_ZONE_DMA32=y CONFIG_AUDIT_ARCH=y CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_X86_64_SMP=y CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx -fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10 -fcall-saved-r11" CONFIG_ARCH_SUPPORTS_UPROBES=y CONFIG_FIX_EARLYCON_MEM=y CONFIG_PGTABLE_LEVELS=4 CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_EXTABLE_SORT=y # # General setup # CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE="" # CONFIG_COMPILE_TEST is not set CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_HAVE_KERNEL_GZI
