Re: Regression in 5.1.20: Reading long directory fails

> "JBF" == J Bruce Fields writes: JBF> Those readdir changes were client-side, right? Based on that I'd JBF> been assuming a client bug, but maybe it'd be worth getting a full JBF> packet capture of the readdir reply to make sure it's legit. I have been working with bcodding on IRC for the

Re: Regression in 5.1.20: Reading long directory fails

I asked the XFS folks who mentioned that the issues with 64 bit inodes are old, constrained to larger filesystems than what I'm using, not an issue with nfsv4, and not present on anything but 32bit clients with old userspace. In any case, I have been experimenting a bit and somehow the issue

Re: Regression in 5.1.20: Reading long directory fails

> "WW" == Wolfgang Walter writes: WW> What filesystem do you use on the server? xfs? Yeah, it's XFS. WW> If yes, does it use 64bit inodes (or started to use them)? These filesystems aren't super old, and were all created with the default RHEL7 options. I'm not sure how to check that 64

Re: Regression in 5.1.20: Reading long directory fails

> "JLT" == Jason L Tibbitts writes: JLT> Certainly a server reboot, or maybe even just JLT> unmounting and remounting the filesystem or copying the data to JLT> another filesystem would tell me that. In any case, as soon as I JLT> am able to mess with that server, I'll know more. Rebooting

Re: Regression in 5.1.20: Reading long directory fails

> "BF" == J Bruce Fields writes: BF> Looks like that's db531db951f950b8 upstream. (Do you know if it's BF> reproduceable upstream as well?) Yes, it's reproducible up in the 5.3.0 RCs as well. However, while trying to do some further bisecting I ran into an odd problem. Now kernels which

Re: Regression in 5.1.20: Reading long directory fails

I now have another user reporting the same failure of readdir on a long directory which showed up in 5.1.20 and was traced to 3536b79ba75ba44b9ac1a9f1634f2e833bbb735c. I'm not sure what to do to get more traction besides reposting and adding some addresses to the CC list. If there is any

Re: [PATCH] scsi: sg: only check for dxfer_len greater than 256M

> "MKP" == Martin K Petersen writes: MKP> Applied to 4.13/scsi-fixes. Thanks! My thanks as well to everyone who helped in getting this fixed. - J<

Re: [PATCH] scsi: sg: only check for dxfer_len greater than 256M

> "MKP" == Martin K Petersen writes: MKP> Applied to 4.13/scsi-fixes. Thanks! My thanks as well to everyone who helped in getting this fixed. - J<

Re: [REGRESSION] 28676d869bbb (scsi: sg: check for valid direction before starting the request) breaks mtx tape library control

> "JT" == Johannes Thumshirn writes: JT> It's probably best to just check for dxfer_len <= 2^28 to be valid JT> as Doug suggested: I can verify that patch on top of git head (as of a few hours ago) does function properly. It didn't apply directly on top of 4.12 but even

Re: [REGRESSION] 28676d869bbb (scsi: sg: check for valid direction before starting the request) breaks mtx tape library control

> "JT" == Johannes Thumshirn writes: JT> It's probably best to just check for dxfer_len <= 2^28 to be valid JT> as Doug suggested: I can verify that patch on top of git head (as of a few hours ago) does function properly. It didn't apply directly on top of 4.12 but even I can handle fixing

Re: [REGRESSION] 28676d869bbb (scsi: sg: check for valid direction before starting the request) breaks mtx tape library control

> "JT" == Johannes Thumshirn writes: JT> Yes please (on top of the snippet I've sent you last). OK, I'm at 4.12 with 68c59fcea1f2c6a54c62aa896cc623c1b5bc9b47 cherry picked, plus the fix patch and the debug patch you've sent previously. To make sure we're on the same

Re: [REGRESSION] 28676d869bbb (scsi: sg: check for valid direction before starting the request) breaks mtx tape library control

> "JT" == Johannes Thumshirn writes: JT> Yes please (on top of the snippet I've sent you last). OK, I'm at 4.12 with 68c59fcea1f2c6a54c62aa896cc623c1b5bc9b47 cherry picked, plus the fix patch and the debug patch you've sent previously. To make sure we're on the same page, I'll include the

Re: [REGRESSION] 28676d869bbb (scsi: sg: check for valid direction before starting the request) breaks mtx tape library control

> "JT" == Johannes Thumshirn writes: JT> Jason, can you try the above? If it works and Doug doesn't respond, JT> I'm inclined yo submit this band aid. Unfortunately it doesn't appear to work for me. Maybe I'm building the wrong thing, though. I checked out 4.12, cherry

Re: [REGRESSION] 28676d869bbb (scsi: sg: check for valid direction before starting the request) breaks mtx tape library control

> "JT" == Johannes Thumshirn writes: JT> Jason, can you try the above? If it works and Doug doesn't respond, JT> I'm inclined yo submit this band aid. Unfortunately it doesn't appear to work for me. Maybe I'm building the wrong thing, though. I checked out 4.12, cherry picked

Re: [REGRESSION] 28676d869bbb (scsi: sg: check for valid direction before starting the request) breaks mtx tape library control

> "JT" == Johannes Thumshirn writes: JT> Can you please apply this debugging patch, so I can see what's going JT> on. Sure, no problem. I generally run "mtx -f /dev/sg7 status" first just to make sure the library is there; this has always worked as expected. With the

Re: [REGRESSION] 28676d869bbb (scsi: sg: check for valid direction before starting the request) breaks mtx tape library control

> "JT" == Johannes Thumshirn writes: JT> Can you please apply this debugging patch, so I can see what's going JT> on. Sure, no problem. I generally run "mtx -f /dev/sg7 status" first just to make sure the library is there; this has always worked as expected. With the debug patch applied,

Re: [REGRESSION] 28676d869bbb (scsi: sg: check for valid direction before starting the request) breaks mtx tape library control

I have verified that building a clean v4.12 with 68c59fcea1f2c6a54c62aa896cc623c1b5bc9b47 cherry picked on top still shows the problem: [root@backup2 ~]# mtx -f /dev/sg7 next 0 Unloading drive 0 into Storage Element 45...mtx: Request Sense: Long Report=yes mtx: Request Sense: Valid Residual=no

Re: [REGRESSION] 28676d869bbb (scsi: sg: check for valid direction before starting the request) breaks mtx tape library control

I have verified that building a clean v4.12 with 68c59fcea1f2c6a54c62aa896cc623c1b5bc9b47 cherry picked on top still shows the problem: [root@backup2 ~]# mtx -f /dev/sg7 next 0 Unloading drive 0 into Storage Element 45...mtx: Request Sense: Long Report=yes mtx: Request Sense: Valid Residual=no

Re: [REGRESSION] 28676d869bbb (scsi: sg: check for valid direction before starting the request) breaks mtx tape library control

> "JT" == Johannes Thumshirn writes: JT> This is fixed with: commit 68c59fcea1f2c6a54c62aa896cc623c1b5bc9b47 Hmm, well, I just pulled and built mainline, which does appear to contain that patch (though it wasn't there when I first started investigating this last week)

Re: [REGRESSION] 28676d869bbb (scsi: sg: check for valid direction before starting the request) breaks mtx tape library control

> "JT" == Johannes Thumshirn writes: JT> This is fixed with: commit 68c59fcea1f2c6a54c62aa896cc623c1b5bc9b47 Hmm, well, I just pulled and built mainline, which does appear to contain that patch (though it wasn't there when I first started investigating this last week) and the problem is

[REGRESSION] 28676d869bbb (scsi: sg: check for valid direction before starting the request) breaks mtx tape library control

After updating my tape backup server to 4.12 I found that mtx had issues controlling the tape library. Good behavior: [root@backup2 ~]# mtx -f /dev/sg7 next 0 Unloading drive 0 into Storage Element 4...done Loading media from Storage Element 5 into drive 0...done Bad behavior: [root@backup2

[REGRESSION] 28676d869bbb (scsi: sg: check for valid direction before starting the request) breaks mtx tape library control

After updating my tape backup server to 4.12 I found that mtx had issues controlling the tape library. Good behavior: [root@backup2 ~]# mtx -f /dev/sg7 next 0 Unloading drive 0 into Storage Element 4...done Loading media from Storage Element 5 into drive 0...done Bad behavior: [root@backup2

Commit 6016af "[media] v4l2: use __u32 rather than enums in ioctl() structs" breaks C++ users of V4L2

I ran into problems compiling the program ZoneMinder on Fedora rawhide (currently using something around 3.5rc6) which do not appear with 3.4 kernels. With help this was traced to commit 6016af82eafcb6e086a8f2a2197b46029a843d68, "[media] v4l2: use __u32 rather than enums in ioctl() structs" which

Commit 6016af [media] v4l2: use __u32 rather than enums in ioctl() structs breaks C++ users of V4L2

I ran into problems compiling the program ZoneMinder on Fedora rawhide (currently using something around 3.5rc6) which do not appear with 3.4 kernels. With help this was traced to commit 6016af82eafcb6e086a8f2a2197b46029a843d68, [media] v4l2: use __u32 rather than enums in ioctl() structs which

Re: Major regression on hackbench with SLUB (more numbers)

> "IM" == Ingo Molnar <[EMAIL PROTECTED]> writes: IM> Distros will likely pick SLUB if there's no performance worries IM> and if it's the default. Fedora rawhide already uses SLUB. Actually, it seems to me that not only does Fedora rawhide use SLUB, but Fedora 8 and 7 use it as well. They

Re: Major regression on hackbench with SLUB (more numbers)

IM == Ingo Molnar [EMAIL PROTECTED] writes: IM Distros will likely pick SLUB if there's no performance worries IM and if it's the default. Fedora rawhide already uses SLUB. Actually, it seems to me that not only does Fedora rawhide use SLUB, but Fedora 8 and 7 use it as well. They don't have

Re: ARC-1260: No space left on device, when there is (or should be) free space left

> "MN" == Magnus Naeslund <[EMAIL PROTECTED]> writes: MN> Inode count: 1430528 That's stunningly small; I created an 8TB partition here and made an ext3 filesystem in it with the default parameters; I got nearly 1000 times as many inodes as you have: Inode count: 1072414720

Re: ARC-1260: No space left on device, when there is (or should be) free space left

MN == Magnus Naeslund [EMAIL PROTECTED] writes: MN Inode count: 1430528 That's stunningly small; I created an 8TB partition here and made an ext3 filesystem in it with the default parameters; I got nearly 1000 times as many inodes as you have: Inode count: 1072414720 Block count:

Re: [PATCH -mm] PM: Separate hibernation code from suspend code

> "AM" == Andrew Morton <[EMAIL PROTECTED]> writes: AM> This causes the long-suffering Vaio to fail to power off during AM> suspend to disk. It says "Please power me down manually". Interesting; I'm seeing exactly the same thing on a Vaio TXN17P, which popped up somewhere between Fedora's

Re: [PATCH -mm] PM: Separate hibernation code from suspend code

AM == Andrew Morton [EMAIL PROTECTED] writes: AM This causes the long-suffering Vaio to fail to power off during AM suspend to disk. It says Please power me down manually. Interesting; I'm seeing exactly the same thing on a Vaio TXN17P, which popped up somewhere between Fedora's 2.6.21-1.2116

Re: [Patch] Support UTF-8 scripts

> "LR" == Lee Revell <[EMAIL PROTECTED]> writes: LR> Is Larry smoking crack? That's one of the worst ideas I've heard LR> in a long time. There's no easy way to enter those at the LR> keyboard! I know folks enjoy trashing Perl these days, but it's not justified in this case. From the

Re: [Patch] Support UTF-8 scripts

LR == Lee Revell [EMAIL PROTECTED] writes: LR Is Larry smoking crack? That's one of the worst ideas I've heard LR in a long time. There's no easy way to enter those at the LR keyboard! I know folks enjoy trashing Perl these days, but it's not justified in this case. From the Perl6-Bible -

Re: usb hotplug problems with 2.6.10

> "JH" == Jack Howarth <[EMAIL PROTECTED]> writes: JH> Alan, I had mentioned a couple weeks back that with kernel 2.6.10, JH> the ability to hotplug usb keys in Fedora Core 2 and 3 has been JH> broken. The true issue is a little more complicated than that. The kernel issue here is that

Re: usb hotplug problems with 2.6.10

JH == Jack Howarth [EMAIL PROTECTED] writes: JH Alan, I had mentioned a couple weeks back that with kernel 2.6.10, JH the ability to hotplug usb keys in Fedora Core 2 and 3 has been JH broken. The true issue is a little more complicated than that. The kernel issue here is that under 2.6.9 (or

Re: 3ware driver (3w-xxxx) in 2.6.10: procfs entry

> "PD" == Peter Daum <[EMAIL PROTECTED]> writes: PD> At least on my 8506-controllers there are also some minor problems PD> (e.g. "info" doesn't work during a verify) which I thought was due PD> to the fact that the program is intended exclusively for PD> 9000-controllers. You should report

Re: 3ware driver (3w-xxxx) in 2.6.10: procfs entry

PD == Peter Daum [EMAIL PROTECTED] writes: PD At least on my 8506-controllers there are also some minor problems PD (e.g. info doesn't work during a verify) which I thought was due PD to the fact that the program is intended exclusively for PD 9000-controllers. You should report the problems